So I am pretty sure that using shorter function names can dramatically increase speed so I decided to try making a function name optimizer program to squeeze out more speed from my .bas programs
Basically, all it does is look for FN.DEF and extract out the function names and enumerate them to (usually) shorter and obfuscated names.
I ran it on some of my programs and got 4-10% savings in code size... (It saved about 10% on GW.bas but I have to re-install the themes to test the demo out).. I use it along with my merge INCLUDE program to reduce source file sizes and hopefully increase interpreter speed and load times
I haven't fully tested it so I am not sure it is perfect so please use at your own risk..
! ! function optimizer/obfuscator ! !
FN.DEF nocasereplace$(s$, f$, r$) start=1 DO i=IS_IN(LOWER$(f$),LOWER$(s$),start) IF !i THEN D_U.BREAK s$=left$(s$,i-1)+r$+right$(s$,len(s$)-i-len(f$)+1) start=i+LEN(r$) UNTIL !i FN.RTN s$ FN.END
! scan for function names DO TEXT.READLN h1, a$ eof=(a$="EOF") IF eof THEN D_U.BREAK
IF IS_IN("fn.def ",LOWER$(a$))
fname$ = LOWER$(MID$(a$,1,i-1))
list.size funcr,siz if siz>1 j=0 do j++ list.get funcr,j,l$ until len(fname$)>=len(l$) | j>=siz LIST.insert funcr,j,fname$ else list.add funcr,fname$ endif
PRINT fname$,fcount ENDIF UNTIL eof PRINT "eof" TEXT.CLOSE h1
GRABFILE prog$, p$ oldl=len(prog$) ! replace function names LIST.SIZE funcr, size FOR i = 1 TO size print i LIST.GET funcr, i, oldf$ newf$="f"+int$(i) if is_in("$",oldf$) then newf$+="$" prog$=nocasereplace$(prog$, oldf$+"(", newf$+"(") PRINT "replaced "+oldf$ NEXT i newl=len(prog$) TEXT.OPEN w, h, "../source/output.bas" TEXT.WRITELN h, prog$ TEXT.CLOSE h
print int$(100*(oldl-newl)/newl)+"% saved!"
input "enter file to optimize", p$ optfn("../source/"+p$)
Joined: Tue Jan 03, 2012 9:31 am Posts: 5446 Location: Paris, France
Yes that is because currently variable lookup (including function names) is linear. It scans names starting at #1: your f2() function, going through the numerous GW functions, and ending at #last: your f1() function. This should change if we manage to switch to a variable binary search.
It's probably not a huge deal since I don't mind sticking the most time critical functions near the top of my source files. Hopefully binary search won't cost too much memory or increase the distribution apk sizes too much.. things run really zippy right now if you do a bit of tweaking. As it is my entire food diary app is only a 650KB apk.. pretty lean!
Ok... so I have been working on my mergeinc program optimizer and ran it on GW demo version 1.9... It shrunk the entire program from 173K down to about 114K
It seems to run a lot faster with the smaller function names. seems to have a weird bug though since I can't get the dialogs to pop up in my optimized version. Might have something to do with spaces in front of function ( 's like fn.def f () instead of fn.def f()
Compare GWdemoopt.bas which is optimized versus the original GWdemooptdev.bas
no problems with BASIC! interpreting spaces around functions.. Just my function name-shortening program isn't smart enough to tell the difference between an expression with parentheses and a function name... I'll work on it more. Thanks.
Users browsing this forum: No registered users and 1 guest
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum