Hmm... good plan. But why do I suspect that the longer a script is, the longer it will take to run? In the "old days", all BASIC programs had to be parsed from the beginning up to the loop or function needed each time it had to test for a new condition. So while even though the loop in use at the time might be smaller and run faster for that particular function, it takes longer for the software to run through the whole thing to find that loop each time. Granted, this isn't hitting the 10ms per line speed-limit, but the uBASIC speed itself, yes? No?
But then, come to think of it, once (or if) the internal shoot command becomes faster, then this will be done away with and whatever fastest method found will have a script just for that purpose.
Isn't it quite easy to test this? Take your MD Lightning script, make it a mile long by adding stuff that never gets run and compare the speed. I would guess that only goto statements get slowed down if stuff gets added before the line the goto points at, and even then not noticeably. Why would the interpreter need to scan through the entire program just to jump to next line?
And even then, the MD reaction time wouldn't slow down, just trigger delay.
Also, I would think that scanning for the goto target is done during the same keyboard interval and that it really shouldn't take a significant amount of time from a processor running at ...umm.. can't remember how fast it was
, sub-1us instruction cycle anyway, quite a bit of code needed to reach 1 ms execution time.
But if you know it slows down, I'm obviously wrong