Have no fear! Today’s installment is a short one. It will address a few miscellaneous things I have been told about.
“.” versus “0”
In a comment posted to Part 5, Darren Atkinson (designer of the fabulous CoCoSDC interface) pointed out a place where a decimal point makes things faster!
One place where a decimal point will give an improvement is when using the value 0 in an expression. Basic will accept a stand-alone decimal point as the number 0, but it will process it faster than the ‘0’ character.
Try comparing the speed of:
IF N < 0 THEN …
with that of:
IF N < . THEN …
– Darren Atkinson
I, of course, had to test this. Using the benchmark program:
0 DIM Z 5 DIM TE,TM,B,A,TT 10 FORA=0TO4:TIMER=0:TM=TIMER 20 FORB=0TO1000 30 Z=0 70 NEXT:TE=TIMER-TM 80 TT=TT+TE:PRINTA,TE 90 NEXT:PRINTTT/A:END
Setting Z=0 1000 times produced the value of 178.
Using a hexadecimal zero produced 164.
And using just a period to represent zero produces … 141!
Okay, no more zeros.
George Phillips chimed in about GOTO and GOSUB with a sneaky way to jump around faster:
However, because BASIC stores lines as a singly linked list the fastest places to GOTO and GOSUB are either the top of the program or anywhere after you do the GOTO/GOSUB. BASIC is clever enough to look forward if the line # is after the current one, otherwise it must search from the top.
Using a “fake” FOR/NEXT loop instead of GOTO could well be faster in such cases since it doesn’t have to search for the start of the FOR. If you have:
… whole bunch of code
1000 PRINT”Here we go.”
… do some stuff
It is likely faster to do this:
1000 FORX=0TO1STEP0:PRINT”Here we go.”
Possibly tricky to use in practice, but you can have a lot of FOR/NEXT loops on the stack and skip over interior ones. Fairly unpleasant, but optimizing BASIC is not a pretty undertaking.
– George Phillips
Wow. James Gerrie and Johann Klasek also mentioned this in response to Part 4. Johann gave an example:
I think something like that was in mind:
20 FOR A=. TO 1: A=. : REM FOREVER
30 ON INSTR(” UDLR”,INKEY$) GOTO 100,200,300,400,500
35 REM FALL THROUGH ACTION
100 REM IDLE LOOP
200 REM MOVE UP
300 REM MOVE DOWN
400 REM MOVE LEFT
500 REM MOVE RIGHT
Compared to the ON GOSUB this is some kind of “redo” or “loop retry” not reaching the fall through action in 35.
– Johann Klasek
Anytime the overhead of scanning through lines (from first line to destination) is more than the overhead of a RETURN, this would be faster (and only use a bit of extra memory for remembering where to RETURN to).
I don’t have any benchmarks for this one, but there is probably a threshold where the number of lines before the GOTO has to be more than X before this is always faster.
Thanks, Darren, James and Johann (and any others I might have missed).
Until next time…