Testing the speed of commands [outdated]
12Me21Created:
If you want me to test a command, or have your own test results (for any commands), post them here.
INC X,N 0.000 36 frames * X=X+N 0.000 29 frames *INC S$,C$ 0.000 38 frames PUSH S$,C$ 0.000 44 frames S$=S$+C$ 0.000 48 frames *INC A[0],N 0.000 49 frames A[0]=A[0]+N 0.000 77 frames INC X 0.000 36 frames INC X,1 0.000 36 frames *DEC X,-1 0.000 33 frames - PUSH A,N 0.000 75 frames UNSHIFT A,N 0.0 1925 frames N=POP(A) 0.000 55 frames N=SHIFT(A) 0.0 1315 frames *X%=X%+1 0.000 92 ms X#=X#+1 0.00 125 ms *GOSUB @TEST 0.00 12 ms TEST 0.00 26 msvariables: A (array), S$,C$ (strings), X,N (numbers) Code used for testing (when results are in frames)
C=MAINCNT FOR I=1 to 100000 'code to test NEXT PRINT "0."+FORMAT$("%05D",MAINCNT-C)
I've done this a few times. Good for code optimization.
What about:
INC X% INC X%,1 DEC X% INC X%,-1 DEC X%,1
My question: Do you do multiple tests of each command? MAINCNT is not super accurate as it only works in frames, so it's best (from what I've found) to test each command about five times and average the results.
I'd like to question the use of OPTION STRICT here. Would that not cause inconsistency in results between strict and non-strict?OPTION STRICT is just a precompiler switch (kinda like turning on warnings on your C compiler.) Without it, the system just auto-creates a VAR for every undeclared variable instead of telling you to do it yourself. There's no inconsistencies; I actually removed the OPTION STRICT and VAR A% since they would make no difference.
I can confirm that INC X is "significantly"' slower than DEC X,-1. DEC and INC are apparently the same speed though EDIT: this is unrelated, but I was looking at that screenshot, and it looked like it had low contrast, but then I realized it was because I'm used to strings being yellow.My tests (which are literally just executing the same statement 100,000 times, no wrapped FORs or anything) have them average out the same. I have to agree to disagree. And FWIW the JPEG compression actually does wash out the colors a bit.
What code did you test?I can confirm that INC X is "significantly"' slower than DEC X,-1. DEC and INC are apparently the same speed though EDIT: this is unrelated, but I was looking at that screenshot, and it looked like it had low contrast, but then I realized it was because I'm used to strings being yellow.My tests (which are literally just executing the same statement 100,000 times, no wrapped FORs or anything) have them average out the same. I have to agree to disagree. And FWIW the JPEG compression actually does wash out the colors a bit.
INC X,1 vs DEC X,-1?
Anyone feel like testing GOSUB against DEFs?Even if GOSUB turns out to be faster, I doubt it'll make much of a difference in anybody's code since labels basically equals spaghetti code. Noooooo I'm going on another functions vs. goto/sub rant! Why does this always happen?! EDIT: GOSUB turns out to have the edge over DEF in speed-exclusive tests.
OPTION STRICT CLS VAR T%=MAINCNT,I% FOR I%=0 TO 1000000 GOSUB @TEST NEXT ?MAINCNT-T% T%=MAINCNT FOR I%=0 TO 1000000 TEST NEXT ?MAINCNT-T% STOP DEF TEST END @TEST RETURNAlso, just tested INC G%,1 vs. DEC G%,-1 and extremely surprisingly, DEC G%,-1 turns out to be faster, as shown in multiple tests.
Yay, testing spree! Real numbers appear to run just slightly slower than integers.