optimizationmicro-optimizationti-basic

Does optimizing code in TI-BASIC actually make a difference?


I know in TI-BASIC, the convention is to optimize obsessively and to save as many bits as possible (which is pretty fun, I admit).

For example,

DelVar Z
Prompt X
If X=0
Then
    Disp "X is zero"
End                   //28 bytes

would be cleaned up as

DelVar ZPrompt X
If not(X
    "X is zero        //20 bytes

But does optimizing code this way actually make a difference? Does it noticeably run faster or save memory?


Solution

  • Yes. Optimizing your TI-Basic code makes a difference, and that difference is much larger than you would find for most programming languages.

    In my opinion, the most important optimization to TI-Basic programs is size (making them as small as possible). This is important to me since I have dozens of programs on my calculator, which only has 24 kB of user-accessible RAM. In this case, it isn't really necessary to spend lots of time trying to save a few bytes of space; instead, I simply advise learning the shortest and most efficient ways to do things, so that when you write programs, they will naturally tend to be small.

    Additionally, TI-Basic programs should be optimized for speed. Examples off of the top of my head include the quirk with the unclosed For( loop, calculating a value once instead of calculating it in every iteration of a loop (if possible), and using quickly-accessed variables such as Ans and the finance variables whenever the variable must be accessed a large number of times (e.g. 1000+).

    A third possible optimization is for run-time memory usage. Every loop, function call, etc. has an overhead that must be stored in the memory stack in order to return to the original location, calculate values, etc. during the program's execution. It is important to avoid memory leaks (such as breaking out of a loop with Goto).

    It is up to you to decide how you balance these optimizations. I prefer to:

    1. First and foremost, guarantee that there are no memory leaks or incorrectly nested loops in my program.
    2. Take advantage of any size optimizations that have little or no impact on the program's speed.
    3. Consider speed optimizations, and decide if the added speed is worth the increase in program size.