Re: ipairs in Lua 5.3.0-alpha

[Jan Behrens <jbe-lua-l@...>]

On Fri, 15 Aug 2014 11:31:30 -0300
Roberto Ierusalimschy <roberto@inf.puc-rio.br> wrote:

> > I just came up with a better idea, which only introduces minimal
> > changes into the language, but allows a removal of the __ipairs
> > metamethod, yet avoiding re-evaluating the length for every
> > iteration step: adjusting Lua's for-statement in such way that more
> > than one state variable can be passed.
> 
> It wasn't you who said that this is not enough?
> 
> | 3. Removing the __ipairs metamethod mechanism is not just about
> |    the overhead (and speed) of the # operator:
> | 
> |    a) Beside the repetitive call of luaB_ipairs, it is not
> |       possible to return a precalculated value as second item of
> |       the iterator triplet that may speed things up.
> |       [...]
> 
> -- Roberto
> 

That must have been another Jan ;-)

Still, caching the result of a __len call would reduce the slowdown
by 100% (in regard of Lua 5.2's speed).

Consider my previously posted benchmark on this:

On Thu, 14 Aug 2014 15:23:19 +0200
Jan Behrens <jbe-lua-l@public-software-group.org> wrote:

> ~/lua_ipairs_test/lua53 % time bin/lua ../constant-length.lua
> 78.034u 0.000s 1:19.64 97.9%    259+172k 0+0io 0pf+0w
> 
> ~/lua_ipairs_test/lua53compat % time bin/lua ../constant-length.lua
> 38.664u 0.000s 0:39.35 98.2%    259+172k 0+0io 0pf+0w
> 
> ~/lua_ipairs_test/lua53 % time bin/lua ../dynamic-length.lua 
> 114.452u 0.007s 1:55.69 98.9%   259+172k 0+0io 0pf+0w
> 
> ~/lua_ipairs_test/lua53compat % time bin/lua ../dynamic-length.lua
> 38.697u 0.000s 0:39.38 98.2%    259+172k 0+0io 0pf+0w

Invoking the # operator is still causing a slowdown of
114.452 sec - 78.034 sec = 36.418 sec (approx 100%).
(Not even counting the Lua function call of __len)


You are right, however, that what I said in 3. a) is still an issue
if __ipairs gets removed as planned. I will do further benchmarks on
this.


Regards
Jan