lua-users home
lua-l archive

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

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


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$

AltStyle によって変換されたページ (->オリジナル) /