I haven't really touched my TI84PSE in about a year. But this morning I decided to finish a project I started a while ago. It was a simple chasing game, really, but the structure of the program was terribad. I'd written it around mid-2008 and had slapped on half-hearted revisions since then to make it run faster, but had never started fresh.
One of the things I wondered, though, was whether my "optimizations" actually did anything. So after failing to time execution with my stopwatch, I wrote a neat little program that would alternately execute two short sample blocks of code in For() loops, while timing them with StartTimer and compiling the execution times (in seconds) of each For-loop, which would run the block of code hundreds of times and hopefully the small discrepancies in efficiency would add up the same way they do in large programs.
I don't trust it completely, though.
As of now I've only tested a few things, but here are my hypotheses that I've tested.
1) Repeatedly incrementing a list with four elements (
Code:
) versus incrementing four letter variables (
Code:
) in an otherwise identical loop. This didn't work too well. The list actually took markedly longer to increment.
2) Colon-combining instructions so that several fit on one line will execute faster. This had no effect on times whatsoever.
Aside from simple stuff, though, I've concerned myself with the efficency of If loops. Here are two hypotheses I made and how they turned out. I'll refer to my experimentally optimized code, the top block in each example, as X1, and the originally formatted code as X2.
1) Given that B is incremented by 1 every iteration, reset to 1 when it reaches 4, and that we want to increment C every time B=3:
Code:
will execute faster than
Code:
This was proven patently untrue, X2 executed faster every time. Although X1 was seemingly more efficient for B=1 and B=2 (only one If), for B=3 and B=4 it had 3 Ifs, which (given even distribution of values for B) makes an average of 2 ifs/cycle, which is the same as X2. I'm guessing X1 performed poorly because even in the case of B=1 and B=2 there's still a craphuge block to skip.
2) Given that B alternates between being 1 and -1 every iteration, and that we want to increment C every time B=1 and decrement C every time B=-1:
Code:
will execute faster than
Code:
This actually worked quite well, I consistently got smaller times with X1. I was afraid they would have equal execution times because of the addition operation in every cycle of X1, but apparently If statements are more expensive. Success, I suppose.
Now here's where I ask for help. Despite my ability to kinda sorta measure execution times with small blocks of code, I have no idea how to clean up my program architecture other than to move around sections and hope for the best. If I use nothing but Repeat, For and While loops in lieu of Lbl() will this speed up overall execution? I've got a Menu() as a pause screen in my game, which IMO is more convenient than a custom-made screen but only works with labels. As long as the actual engine of the game is controlled with Repeat loops (that watch for enemy collisions), will this have any effect?
One of the things I wondered, though, was whether my "optimizations" actually did anything. So after failing to time execution with my stopwatch, I wrote a neat little program that would alternately execute two short sample blocks of code in For() loops, while timing them with StartTimer and compiling the execution times (in seconds) of each For-loop, which would run the block of code hundreds of times and hopefully the small discrepancies in efficiency would add up the same way they do in large programs.
I don't trust it completely, though.
As of now I've only tested a few things, but here are my hypotheses that I've tested.
1) Repeatedly incrementing a list with four elements (
Code:
L1+1->L1Code:
A+1->A:B+1->B:C+1->C:D+1->D2) Colon-combining instructions so that several fit on one line will execute faster. This had no effect on times whatsoever.
Aside from simple stuff, though, I've concerned myself with the efficency of If loops. Here are two hypotheses I made and how they turned out. I'll refer to my experimentally optimized code, the top block in each example, as X1, and the originally formatted code as X2.
1) Given that B is incremented by 1 every iteration, reset to 1 when it reaches 4, and that we want to increment C every time B=3:
Code:
If B>2
Then
If B=3
C+1->C
If B=4
1->B
Endwill execute faster than
Code:
If B=3
C+1->C
If B=4
1->BThis was proven patently untrue, X2 executed faster every time. Although X1 was seemingly more efficient for B=1 and B=2 (only one If), for B=3 and B=4 it had 3 Ifs, which (given even distribution of values for B) makes an average of 2 ifs/cycle, which is the same as X2. I'm guessing X1 performed poorly because even in the case of B=1 and B=2 there's still a craphuge block to skip.
2) Given that B alternates between being 1 and -1 every iteration, and that we want to increment C every time B=1 and decrement C every time B=-1:
Code:
C-1->C
If B=1
C+2->Cwill execute faster than
Code:
If B=-1
C-1->C
If B=1
C+1->C
This actually worked quite well, I consistently got smaller times with X1. I was afraid they would have equal execution times because of the addition operation in every cycle of X1, but apparently If statements are more expensive. Success, I suppose.
Now here's where I ask for help. Despite my ability to kinda sorta measure execution times with small blocks of code, I have no idea how to clean up my program architecture other than to move around sections and hope for the best. If I use nothing but Repeat, For and While loops in lieu of Lbl() will this speed up overall execution? I've got a Menu() as a pause screen in my game, which IMO is more convenient than a custom-made screen but only works with labels. As long as the actual engine of the game is controlled with Repeat loops (that watch for enemy collisions), will this have any effect?
