[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Non-copying varargs (Was: Re: inadequate documentation for select and table.unpack)
- From: Dirk Laurie <dirk.laurie@...>
- Date: Tue, 21 Jun 2016 07:57:50 +0200
2016-06-20 23:27 GMT+02:00 Soni L. <firstname.lastname@example.org>:
> On 20/06/16 05:02 PM, Dirk Laurie wrote:
>> 2016-06-20 21:04 GMT+02:00 Roberto Ierusalimschy <email@example.com>:
>>>> A point that does rate some extra explanation, but perhaps iin PiL
>>>> rather than the reference manual, is that 'select' is in fact an
>>>> extremely efficient operation, involving no actual copying of
>>>> arguments. There is no API equivalent, because none is needed.
>>>> It returns the stack exactly as it found it, but reporting a possibly
>>>> different number of return values.
>>> That is not true. 'select' can be quite slow for a large number of
>>> parameters (where "large" starts in the order of a few dozen). In
>>> particular, a typical loop in a vararg function using 'select' is
>>> quadratic with the number of arguments, while creating a table and
>>> traversing it is linear.
>> Could you explain why that happens? luaB_select is clearly O(1).
>> Does VARARG copy the arguments? If so, why is that necessary?
> It's not strictly necessary, but the solution involves a linked list and
> If not handled right, debug.setlocal would affect multiple varargs lists
> instead of just one
So the only track debris blocking the racing-car is the Lua counterpart
to BASIC's POKE?
O(n) instead of O(1), on a function so essential that it is not even
wrapped in a sublibrary but supplied directly in _G, seems to be
a large price to pay for a specialized tool that we are enjoined to
"exert with care when using".
Can't we rather have fast VARARG plus a warning in debug.setlocal
that its use on functions that have '...' is even more perilous than the
rest of the debug library?
> Thus, while I'd greatly benefit from non-copying varargs (I even thought
> about proposing this once), it would be a maintenance nightmare for the Lua
> And I didn't even mention the interaction between this specific varargs
> implementation and multiple returns...
It seems that even select('#',...) generates VARARG.