Re: ipairs in Lua 5.3.0-alpha

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

On Fri, 15 Aug 2014 16:53:55 +0200
Jan Behrens <jbe-lua-l@public-software-group.org> wrote:

> I will do further benchmarks on this.


I just created a patched Lua 5.3, which differs from Lua 5.3-alpha as
follows:

--- lua-5.3.0-alpha/src/lbaselib.c      2014-07-24 21:33:29.000000000 +0200
+++ lua-5.3.0-alpha-staticlen/src/lbaselib.c    2014-08-15 17:17:32.078783582 +0200
@@ -260,7 +260,11 @@
 */
 static int ipairsaux (lua_State *L) {
   int i = luaL_checkint(L, 2) + 1;
-  if (i > luaL_len(L, 1)) {  /* larger than length? */
+  int maxi;
+  lua_settop(L, 2);
+  lua_pushinteger(L, 10000);  
+  maxi = luaL_checkint(L, 3);
+  if (i > maxi) {  /* larger than length? */
     lua_pushnil(L);  /* end traversal */
     return 1;
   }

This is to simulate the length being passed as 3rd argument to
ipairsaux.

Now I reused my benchmark:

========================================
dynamic-length.lua:

datatable = {}

for i = 1, 10000 do
  datatable[i] = tostring(i)
end

proxytable = setmetatable({}, {
  __index = datatable,
  __len = function() return #datatable end,
  __ipairs = function(t)
    return ipairs(datatable)
  end
})

local yes = 0
local no = 0

for i = 1, 10000 do
  for j, v in ipairs(proxytable) do
    if v then yes = yes + 1 else no = no + 1 end
  end
end
========================================


Result with the unpatched Lua 5.3-alpha *without* LUA_COMPAT_IPAIRS:

~/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


Result with the unpatched Lua 5.3-alpha *with* LUA_COMPAT_IPAIRS:

~/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


Result with the *patched* Lua 5.3-alpha *without* LUA_COMPAT_IPAIRS:

~/lua_ipairs_test/lua53patched % time bin/lua ../dynamic-length.lua
51.611u 0.007s 0:52.27 98.7%    259+172k 0+0io 3pf+0w


I would thus conclude that my previously brought up argument in 3. a)
is valid, but only results in a slowdown of a factor of 1.33
(51.611 seconds versus 38.697 seconds).

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

> 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.


Regards
Jan