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

Question

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?

Answer 1

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.

Answer 2

TI-BASIC is an interpreted language, which usually means there is a huge overhead on every single operation.

The way an interpreted language works is that instead of actually compiling the program into code that runs on the CPU directly, each operation is a function call to the interpreter that look at what needs to be done and then calls functions to complete those sub tasks. In most cases, the overhead is a factor or two in speed, and often also in stack memory usage. However, the memory for non-stack is usually the same.

In your above example you are doing the exact same number of operations, which should mean that they run exactly as fast. What you should optimize are things like i = i + 1, which is 4 operations into i++ which is 2 operations. (as an example, TI-BASIC doesn't support ++ operator).

This does not mean that all operations take the exact same time, internally a operation may be calling hundreds of other functions or it may be as simple as updating a single variable. The programmers of the interpreter may also have implemented various peephole optimizations that optimizes very specific language constructs, e.g. for(int i = 0; i < count; i++) could both be implemented as a collection of expensive interpreter functions that behave as if i is generic, or it could be optimized to a compiled loop where it just had to update the variable i and reevaluate the count.

Now, not all interpreted languages are doomed to this pale existence. For example, JavaScript used to be one, but these days all major js engines JIT compile the code to run directly on the CPU.

UPDATE: Clarified that not all operations are created equal.