Optimizing SmileBasic code

There is a lot of interest in how to make Petit Computer programs run faster, so this page is for a collection of optimizations.

Note that generally, optimizations are very bad for readability. Putting too much emphasis on optimization is a common beginners' mistake, because the benefits of readability are not as apparent or compelling until one has had more programming experience. Readability is important for maintainance (if a new bug is discovered, it will help greatly in locating the source(s) of the bug and fixing it without breaking something else), for expandability (if a new feature is to be added, readability makes it much easier to figure out how and where to add it), and for robustness (any kind of tinkering with highly-optimized code is more likely to cause a bug that's more difficult to diagnose and fix). The optimizations below will generally give an improvement of only a few percent at best. As a contribution to the programming community, readability is much more valuable than a few percent speed gain. But, since many contributions are not for the programming community to analyze and learn from, but instead are for the game-playing community to play, there is value in having a list of optimizations for use when the design is finalized and the bugs are fixed and the author doesn't care if others want to learn from or tinker with the code.

Now for the actual list of optimizations (unless otherwise noted, these optimizations have only been observed on a 3DS running SmileBasic V2):


 * takes time. Copies of the code in-line will run faster.


 * loops take time. If a section of code is to be repeated a fixed number of times, copying the code will run faster than looping the code.


 * is faster if it does not have a variable name.


 * If the branches of an  command are executed with 50/50 probability, it is faster overall to have the shorter branch be   and the longer branch be  ; if the branches take an equal amount of time, it is faster to have the more commonly executed branch be   and the less commonly executed branch be.


 * Blank lines take time, comments take more time, and longer comments take yet more time.


 * Removing unneeded spaces speeds things up (e.g. instead of, use  ).


 * Having commands on successive lines is faster than using, the command separator, but faster yet is having commands follow one another without a command separator (e.g.   or  ).


 * Shorter variable names are faster.


 * Shorter labels are faster.


 * An integer numerical literal is faster without a decimal point following it, and a numerical literal without a decimal point is faster than reading a numerical variable.


 * Using the empty string literal is faster than referencing a string variable that contains the empty string.


 * A  that takes the same number of iterations without a   is faster than one with a   (e.g.   is faster than  ), and a positive   value is faster than a negative   value (e.g.   is faster than  ).


 * Having  will speed up code.


 * The quote character to close a string literal is optional if it is at the end of a line: surprisingly, it is faster to include the final quote than it is to omit it.


 * Where you have, it can sometimes be faster to have  .  Note that this is not always faster, sometimes it is slower; it is most effective when   is rarely true, and/or   takes a long time to compute.  Also note that if there are   branches, care will need to be taken, and this may make   the faster option.


 * is generally faster than, and both are faster than.


 * before a value is faster than  after it.    before a value is faster than   after it.  Note that   has a higher precedence than   and , so extra parentheses may be necessary, which then make the expression slower.


 * Finally, it is worth noting that  is not faster than  .  Apparently, the code gets tokenized before it gets run.