Added INSTR library member

[The Beez]

Hi 4tH-ers!

I know what you're thinking: "INSTR? Why? Didn't we have SEARCH?" - and you would be right. But I never really liked what SEARCH came up with as a result. And I think it's horrible to implement.

INSTR just returns the position (either a pointer or an index) or a flag if it went wrong. Plus - and here it comes - it is 50% - 200% faster than SEARCH. It does this by first evaluating the character at hand before calling COMPARE, while COMPARE is called for each character in SEARCH.

On my machine it does a million "finds" per second in case insensitive mode. That's not too shabby IMHO. Fun fact: I developed this one first on uBasic/4tH before porting it to 4tH.

Hans Bezemer

[The Beez]

Another funfact: The routine starts with some heavy stack juggling to get the stack elements in their proper positions. This code was generated by STACKOPT.4tH. It allows for much less stack juggling for the rest of the routine.

Hans Bezemer

[The Beez]

Four lines - and I integrated this one into uBasic as the FIND() command..

Yeah. Really a "write only" language.

Hans Bezemer

[The Beez]

Was it worth to introduce FIND() to uBasic? Well, it's available in many BASICs as INSTR(). The example program IBEFOREE.BAS used it extensively.

• I had already defined a _Search() user defined function. That one finished the task in 100s;
• The _FSearch() function was a big improvement. It brought the runtime down to 45s - more than half;
• The native FIND() function crushed that improvement by finishing the task in 7.5s - that's about six times faster than the previous iteration!

So I'd say it's worth it!

Hans Bezemer

[The Beez]

Well, it didn't leave me alone, so I had to make another INSTR word. This one is smaller, theoretically a bit faster and doesn't rely on COMPARE. I added it to uBasic (it's a drop in replacement so there was not much to do) and it worked just fine. It just made the executable a bit smaller, but no performance improvements.

Hans Bezemer