Optimizing HPP program

[Oulan]

Yes, this program is a bit strange but is related to 'Major bug on G2'

• yes, I know that local variable are faster but 'persistent' such as 'A..Z' are even faster, I use them as 'C register qualified' essentially in 'FOR' loops. See second program to test loop variables. local is at 4.0 seconds, global at 4.5 seconds and persistent at 2.4 seconds.
• the local functions are here to avoid the tests in the CASE structure (average of 8 in this example), when your program is short with few functions (under 20), EVAL is a winner. I made a small test and when I saw this I tried on a larger scale but due to linear search, it does not scale, too bad.
• see previous point. With few functions and globals EVAL is a real winner. Test without the 100 local functions is at 3.7 seconds with EVAL and 5.5 seconds with direct code in the CASE structure.
• FOR loops are just here to make some load, real functions can bee seen in 'Major bug on G2'
  

So if I understand correctly, {'f0','f1',..} is not stored as list of 'direct_reference' to the functions? but as "string" and a search is done in the unordered list of local stuff {local variables + local functions} or is it the {}(index) which is done in linear time ? (I don't think so, in this case the search time should be constant).

If so, this mean that you should not declare too much local stuff, perhaps it is better to use Lists to hide the search at a second level. And we should break the app with smaller units (more hpprgm outside the main hppgm of the app) ? But the problem of the exported variables will raise again (and also the problem of circular use of exported variables (egg&chicken pb)).

Btw did you reproduce the bug in 'Major bug on G2' ? It can need several runs before hitting the 'reboot'

Anyway I am very pleased with the prime, HPP langage is quite nice and rather fast (around the level of non optimized C code on a TI83PCE) which is really good.

I will try other way to optimize (perhaps list constructions ...)

EDIT:

I made other tests on this kind of program. Conclusion is: any kind of call (fxx(), EVAL('fxx')) will take more time if you have more functions defined. Even if you call the first function or the last one ... this is strange I don't completly understand this behavior ... (perhaps linked to the hiden parser and structure).

Olivier