Indeed that variant easily "yields" execution times around 190 ticks, or so. OTOH, the speed limiting factor seems to be the overhead of string concatenation and assignment, so you can't expect the routine to become much faster in BASIC (regardless of pure CBM or slightly enhanced but still general string ops in WimBasic). If string reversal was a cricital bottleneck in a program, that was a candidate for a quick translation to ML, doing an in-place operation.wimoos wrote:I think I must have built the string from the other end, so an L-I expression was executed unneccesarily 255 times.
The string routines in CBM BASIC *are* tuned to quick turn-around times. And still quite compact, with little house-keeping necessary in the average case (without GC).Using Left-MID$ makes it possible to reuse stringspace, thus saving memory and costly garbage collections.
Of course adding a backdescriptor speeds up the GC tremendously with just a small extra memory footprint for each active string (2 bytes). Still, with V2 BASIC you need a least a high 2 figure number of strings for the GC to become easily noticed: in VICtoria Gold for example the fill procedure for the regions in the maps extensively uses data in strings - and stops now and then for 1/2 second in a GC.
If a program needs to handle larger amount of strings, you can always translate those parts to ML, as above. That's what I did with the storage and word-wrap procedures in MG BROWSE. If I had written those routines in BASIC they'd be two orders of magnitude slower, regardless of GC's or not. But string processing in ML is moving data around with no strings attached - much easier to program that in BASIC. And exactly those parts I left in BASIC for the main program of MINIPAINT (preparation of file names for tape/disc access).
Edit:
With an even string length, that FOR loop exchanges the middle two characters twice. The FOR loop should run from 0 to L/2-1 instead.wimoos wrote:Code: Select all
40 FORI=0TOL/2:£X=PEEK(£R-I):POKE£R-I,PEEK(£Q+I):POKE£Q+I,£X:NEXT