lua-users home
lua-l archive

Re: table.unpack(...) and the __index metamethod

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



On 13/06/2014 21:09, Tim Hill wrote:
[fakedme@gmail.com> wrote:


On 13/06/2014 20:10, Tim Hill wrote:
[andrew.starks@trms.com> wrote:


> For performance reasons, all table accesses (get/set) performed by
> these functions are raw.


This makes sense to me. When I use unpack, it is very often in a spot where an expensive operation would be unwelcome.

However, I don't like these kinds of... "exceptions to the rules". Lua has metatables, I don't like to have to think about whether or not the standard library will respect them, or not. 

In the 5.1 era, when __ipairs wasn't around, the exception had a powerful reason: ipairs won't see your sequence and so neither will unpack. But now, it would be nice to see symmetry and "raw*" versions of the non-metatable variety, if the extra speed is needed... or some other, better method of achieving the same goal.

This is relevant to broader Lua because if I expect my module's table to be unpacked, then I need to export it as a "literal", as opposed to an object where the sequence is calculated.

-Andrew

The OP has a point though (imho) … table.unpack() is an iterated operation (internally), so the check for a metamethod could be done ONCE and so incur very little overhead for any non-trivial unpack operation, so you can get both performance *and* flexibility.

—Tim

We need a table.rawunpack(...)?

No, the OP pointed out that the overhead of doing the metamethod test in table.unpack() is low, since it can be done once at the start of unpack(), which then chooses a (fast) rawgeti() based loop or a (generic) index metamethod loop. So you get the best of both worlds in one API.

—Tim

What if we want raw unpacking of metatabled tables? (aka keep nil as nil)

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