[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: lua-5.2.0-alpha table module problem
- From: Keith Matthews <keith.l.matthews@...>
- Date: Wed, 15 Dec 2010 22:02:49 -0500
On Wed, Dec 15, 2010 at 11:43 AM, steve donovan
<steve.j.donovan@gmail.com> wrote:
> On Wed, Dec 15, 2010 at 4:51 PM, Keith Matthews
> <keith.l.matthews@gmail.com> wrote:
>> This change is easy to make in ltablib.c, and it opens up very
>> intersting possibilities such as table virtualization, or table
>> operations on any userdata that has __len, __index and __newindex
>> metamethods. You could make a userdata that wraps a C array, and use
>> table.sort(), table.concat() or table.unpack() on it.
>
> That _is_ an entertaining possibility. What would be the performance
> implications?
>
I wondered about that myself, so I tried it out. When blindly
replacing all calls to lua_rawseti and lua_rawgeti in ltablib.c with
calls to lua_gettable and lua_settable, the performance hit is
unacceptable (anywhere from 1x to 5x slower, depending on the table
length and the function.)
There is a way to avoid that speed penalty when raw access is
possible. At the beginning of every function in the table module, the
metatable would be inspected, and raw access would be used when
possible. That way, for tables with which the table module can be used
right now, there would be no speed difference.
Would anyone be interested if I posted a copy of ltablib.c from
lua-5.2.0-alpha with that change?
- Keith