Re: Changes to iterators in 4.1-work4

[Tom Wrensch <twrensch@...>]

On Sun, 17 Feb 2002, Edgar Toernig wrote:

> Tom Wrensch wrote:
> > 
> > In short his feature is seriously cool.
> 
> Calm down ;-)  Sure, it's nice.  But it's not for free - it's
> pretty heavy weight.  Because the for-statement does not manage
> any state for the iterator one has to create a closure each time.
> I.e. your indexiter creates three (short living) GC'ed objects.
> And the function call costs too.  Something one should realize
> when using this feature.  

Okay, okay, I'm calm. I breathed in to a paper bag for a few minutes and
that helped.

Seriously, I expected some overhead, roughly on par with what you reported
(though I am impressed with the speed of Sol's for-over). There are two
aspects of my use of Lua that make this a good thing anyway. First, I
usually use Lua as a scripting language on a high-end PC or Unix
box. I do some embedded programming, but Lua is way to heavy-weight for
the size processor I work on (usually PIC16F84's or something
similar). Second I'm of the camp that believes code should first be
written clearly and then optimized as necessary. Optimizing as you go is
only effective if you're *really* good, and I'm not.

Thanks for the numbers, saves me the trouble of doing the same tests
myself.

 
> Some numbers about the loop overhead:
> 
> function iter(t)
>   local i=0
>   return function() i=i+1 return t[i] end
> end
> 
> local t={"a","b","c","d"}
> for i=1,1000000 do
>   --for j=1,getn(t) do local j=t[j] end    -- Lua: 12.0s
>   --for j in iter(t) do end                -- Lua: 28.2s (includes ~4900 gc cycles!)
>   --for j=1,t:getn() do local j=t[j] end   -- Sol: 10.8s (dispite old vm?!?)
>   --for j over t do end                    -- Sol:  4.1s
> end
> 
> Ciao, ET.
> 
> -- 
> irc.openprojects.net #lua
>