 |
lua-l archive |
|
|
||
|
Am 14.04.2014 07:49 schröbte Coroutines:
On Sun, Apr 13, 2014 at 10:33 PM, steve donovan <steve.j.donovan@gmail.com> wrote:Ah, but Lua never had pack()/unpack() like you describe - they were just put into the table namespace.I mean bring back the function names, but change their functionality -- I wouldn't want these called anything else, I mean to say.
We would have to choose an appropriate namespace for them. Using an extra "vararg" table for two functions seems overkill, but putting an unpack (incompatible with the one in Lua 5.1) into global scope will probably be error prone and confusing.
That is, pack makes a table from varargs. Are you thinking of the pack defined in that varargs library?I do mean the functionality of the pack() function in the vararg library: https://github.com/moteus/lua-vararg/blob/master/vararg.c#L78
I do like that library, but since it isn't yet ported to Lua 5.2 and nobody has complained, it obviously isn't used much. To be fair, the only two things I wanted to do with varargs (besides what is possible with `select` and tail calls) is chopping of elements at the end of a vararg (I'd suggest negative `select` indices but those are already used for something else) and merging two vararg lists together.
It looks like it stores varargs as upvalues in a closure -- if one were to 'share' the function the closure is derived from then memory could be kept low, but I believe this could be made lighter if "slices" of the lua stack could be packed into a userdata.
They are the same. An empty userdata is 40 bytes in Lua 5.1 on x86_64. You'd need additional 16 bytes per Lua value. A C closure using two upvalues is 72 bytes (which is 40 + 2*16). On Lua 5.2 an identical C closure gets down to 64 bytes, but I haven't measured an empty userdata for that version (no `newproxy` anymore).
I can't see how existing pack can be made more efficient - the varargs need to be stored, and a table is a natural container for them.The underlying struct for a table and its nodes is pretty extensive, as it can mold itself into an array or hash table, and keeps track of the length of each portion: http://www.lua.org/source/5.2/lobject.h.html#Table
An empty table is 64 bytes + 16 bytes per array element (again on x86_64) -- not that bad either.
Philipp