OpenEuphoria

Re: Rob: List?

• Posted by Vincent <darkvincentdude at yahoo.com> Mar 21, 2006
• 587 views

CChris wrote:

>> 6. front-end optimization of temps - fewer temps gives better performance

>> 7. try again to speed up scanning/parsing/emiting (front end)

> Are you sure the time you'll spend in these tricky optimisations will not 
> outweigh the sum of all execution time gains achieved through them? 
> Perhaps most Eu users still use 486s or older, in which case these are
> relevant.

> If not, see my final comments.

#6 is a very important. In some cases it can cause a very large performance
drop. I dont know how effective Rob will be at improving this for us, but I will
say anything is better than nothing.

#7 is useful on all systems five years old or more. You will see a very
noticable parsing delay even on a Pentium III machine when trying to run a large
program like Win32Lib IDE. On a 386 or 486 any medium to large size program will
take between tens of seconds to a few minutes to load. The IDE takes almost four
minutes to load to the splash screen on my 486 with v2.5!

So yes, I strongly support these optimization efforts and look forward to them.
I'm not expecting any miracle improvements but at least marginal will suffice.
Whatever Robert can do to improve these to his maximum ability is all that I
could hope for.

>> 8. Translator optimizations:
>>      - translator: if a call_proc/call_func has an argument sequence where
>>        all the elements are known to be integers, we shouldn't bother to
>>        emit Ref's on the elements

>>      - could easily optimize code generation for compare() in translator

> Ok, these are probably useful. When I *really* (and rarely) need raw speed,

> I directly code in C if asm is not an option. Here again, are these little 
> optimisations worth your efforts?

Any optimizations are worth the effort in Euphoria at least. One of the biggest
selling points of Euphoria is it's performance as an interpreted language. If
that did not count we'd likely be better off using Python or Ruby with complete
standard libaries and large supportive communities.

> CChris


Regards,
Vincent