<background>Through the years, we have been surprised by what affects the speed of TI-BASIC code:

* For( loops without a close-paren are slower with single-line If/IS>/DS< on the first line. (Still don't understand exactly why...)
* Strings aren't random-access, yet lists are: sub(Str1,10000,1) is much slower than sub(Str1,1,1) but sum(L1,999,1) is just as fast as sum(L1,1,1) (this is due to the fact that strings must be tokenized on the fly to find the index, due to two-byte tokens).
* StoPic is absurdly fast. (Makes sense, just writing to memory)
* Multiplication is faster when the second operand has fewer significant digits, except when the first operand is 0. (Makes sense when we consider the underlying routine
* Cubing a complex number is very slow. (There's no bcall for it, so it uses the pow routine just like C^3 would.)
* After a RAM clear, the real variables are just as fast to access as Ans, but before the RAM clear they are significantly slower. (Don't understand this one either, but I can at least imagine a reason why.)
* Moving code from the interpreter to internal routines is faster, even if it's ten times the work.

Et cetera; I've probably missed 90% of them. I understand most, but this latest one baffles me. </background>

Back in mid-July, Earthnite wrote this post on tibasicdev. Basically, programs are much faster after all memory is cleared. I can't understand why, since the parser either operates in RAM (the FP stack, etc) or in flash in fixed locations (system calls). Another user was able to reproduce this, but I have not.

What causes this marked timing difference?

Educated guess: VAT lookup times.

Well, just wanted to point out that this is illegal:

Code:

At most you can get 9999 for each argument.


Because of flash wait states, basically. RAM generally has faster access times.

This one seems pretty obvious, a multiplication is just a bunch of additions... If you do 2*153, then you have to add 2 153 times (although there are probably some things that make it faster like 2*2000 is just 2*2 and add three zeros, switching the numbers around so that the biggest one is first, or dividing a number into it's prime factors and multiplying those (Maybe these would be longer, idk)) but if you have 153*2, then you only need to add 153 twice... so you wouldn't need to do any other operation on it, which of course makes it slightly faster... As for the 0, well that's just 0 you don't even need to look at the rest of the problem xD. That would be my thought process as to why multiplication speed is mostly affected by the second digit.

* Moving code from the interpreter to internal routines is faster, even if it'sten times the work. 
Instead of adding more arithmetic modules to the ALU, they do this...

Well, I would say that the Basic interpreter needs to store things in Flash aswell as in RAM... That is the only explanation I could think off, or maybe TI added a delay depending on the amount of free Flash, to make coding not that boring for us

Edit:


How do you mean that?

Sorry for the confusion; I knew why the multiplication thing was from the previous thread.

Mateo, I think I now see how the state of the RAM after a RAM clear is different from the state of RAM after a full memory clear. Tell me if I misunderstand anything:

* Looking up a variable in the VAT entails going through each entry and checking if its type, name, etc. match.
* Accessing the value of a real variable entails looking it up in the VAT, and then copying the 9 bytes from (address) to OP1, or somewhere.
* Clearing RAM deletes some variables (the ones not archived), causing a partial speedup.
* Even when RAM is cleared, the archived variables still have references in the VAT, therefore, clearing all memory also deletes references to archived variables and gives a greater speedup, especially with many archived variables.

I understand now why I couldn't reproduce: my testing code was an empty 10000-iteration loop with the system variable n as the index, so nothing needed to be looked up.

But how does a GarbageCollect clear the VAT and cause faster access? Also, could you further explain your earlier comment about flash wait states?

Worth pointing out that that's not at all how multiplication works on a calculator. Computers do multiplication essentially the same way we do it on paper with long multiplication. As for specifically how TI's version works, I'm not qualified to say, but it most certainly isn't just performing addition repeatedly.




The flash memory is not as fast as RAM (as you might expect), so whenever the processor reads a value from flash memory it adds "wait states" that make it take longer to read. Without these wait states, the processor might read an incorrect value from flash memory, leading to buggy or crashy results. Just so I don't get lynched, others will point out that the number of wait states added is higher than really necessary, but regardless they are there. The end result is anything that runs from flash memory or reads data out of flash memory will be slower than the same program using RAM.

Thanks for pointing that out, however, you run into the same kind of issue with long multiplication, which is that if you have more digits on the bottom row, the 2nd part of the multiplication (when you add the results together to get your final answer) you will have more numbers to add together (one for every digit on the bottom row) This is why when doing it on paper, elementary teachers suggest putting the smaller numbers at the bottom...

Here I multiplied 2*345, notice how the first way, you have to add 0,60 and 900, the second way however gives the answer directly...

My guess too. Metroid II Evolution for the 84+ ran slower and slower as the project neared completion and grew in size, even with no code changes to the walking engine. I had similar issues with every large game I created, but Metroid II was the most affected.