OpenEuphoria

Re: Object Euphoria optimiztion

• Posted by Michael Nelson <mike-nelson-ODAAT at WORLDNET.ATT.NET> Feb 10, 2000
• 853 views

------=_NextPart_000_0032_01BF73DD.DB610B00
        charset="Windows-1252"


-----Original Message-----
From: jiri babor <jbabor at PARADISE.NET.NZ>
To: EUPHORIA at LISTSERV.MUOHIO.EDU <EUPHORIA at LISTSERV.MUOHIO.EDU>
Date: Thursday, February 10, 2000 4:03 AM
Subject: Re: Object Euphoria optimiztion


>Mike Nelson wrote:
>
>> Some advice about optimiztions for speed:
>> 1.  Minimize type checking--particularly avoid rechecking the same
>>     data when possible.
>> 2.  Avoid nested procedure calls--inline simple routine code.
>> 3.  Similarly, avoid recursion.
>> 4.  It is much faster to search sevaral short sequences than one
>>     huge sequence.
>> 5.  Use variables to reduce repetitive subscripting.
>
>
>Just a few comments.
>
>I am in complete agreement with you on points 1 and 5. In fact I have
>always maintained, rightly or wrongly, type checking is nothing more
>than a debugging tool of dubious value.
>
>I think your second point is probably not terribly important. Routine
>calls are incredibly cheap in Euphoria, in comparison with just about
>any language I know. So unless you are dealing with very short
>innermost loops of millions of cycles, it's not worth the trouble
>trying to unroll them.
>
>And similarly, your advice against recursion is marginal. Once again,
>recursive calls in Euphoria are very efficient, and it's generally
>very difficult to find faster alternatives to well designed, tight
>recursive routines.
>
>Finally, I have never seen any evidence for your claim under number 4.
>I have tested the speed of find() many times, and it seems to be
>simply linear with the traversed length. Chopping up sequences just
>simply adds to overheads.
>
>jiri
>

Jiri,

The file benchmark.ex I am attaching should provide ample proof how much
faster it is to search short sequences--by the way, by "short" I mean small
number of elements.  Benchmark.ex  searches a 2500-element sequence for a
string then searches a 50-element sequence for the first half of a string
and uses the result as the subscript for a 50-by-50-element sequence and
searches the subsequence for the second half of the string.  These are the
results:

100000 searches of 2500 element sequence in 26.96 seconds.
100000 searches of 50 by 50 element sequence
indexed by search of 50 element sequence in 0.61 seconds.

I would say that a 97.7% reduction in execution time is  worth a little
complexity.  Of all the benchmark tests I ran before starting the OE
optimization, this is the most impressive.  Perhaps this clarifies my point
#4.

Points #2 and #3 are marginal but worthwhile if you want to squeeze out the
last drop of performance--calls in Euphoria are very cheap but not free.

-- Mike Nelson



------=_NextPart_000_0032_01BF73DD.DB610B00
        name="benchmark.ex"