Re: Issues with the current varargs implementation (Was: Re: inadequate documentation for select and table.unpack)

[Dirk Laurie <dirk.laurie@...>]

2016-06-22 15:16 GMT+02:00 KHMan <keinhong@gmail.com>:
> On 6/22/2016 8:39 PM, Dirk Laurie wrote:
>>
>> 2016-06-22 12:21 GMT+02:00 steve donovan:
>>>
>>> On Tue, Jun 21, 2016 at 10:47 PM, Philipp Janda:
>>>>
>>>> First of all: vararg performance is fine. .... Performance of `select`
>>>> is fine too.
>>>> Calling it means pushing all of its arguments to the Lua stack -- like
>>>> for any
>>>> other function.
>>>
>>>
>>> I also wonder whether we're going to squeeze much more performance out
>>> of this lemon, and whether this is in fact an important lemon.
>>
>>
>> It is unimportant in the sense that whether traversing the vararg
>> using select is O(n) or O(n²) seldom matters in practice.
>>
>> It is important in the sense that it is highly instructive to ponder
>> the issues involved.
>
> [snip snip]
>
> Hmmm... anyone got an artificial benchmark to test and compare timings? I
> don't believe I've seen any timing data so far...

~~~ {benchmark.lua}
function f(...)
  local function g(...)
    return select('#',...)
  end
  local t={}
  for k=1,select('#',...) do
    t[k]=g(select(k,...))
  end
  return t
end

n=tonumber(arg[1])
print(#f(string.byte(("1"):rep(n),1,-1)))
~~~~

…/tmp$ time lua xxx.lua 10000
10000

real    0m0.315s
user    0m0.311s
sys    0m0.004s
…/tmp$ time lua xxx.lua 50000
50000

real    0m9.695s
user    0m9.679s
sys    0m0.004s
…/tmp$