[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: LuaJIT FFI __gc metamethod?
- From: Josh Haberman <jhaberman@...>
- Date: Mon, 21 Feb 2011 22:25:17 +0000 (UTC)
Mike Pall <mikelu-1102 <at> mike.de> writes:
> Ouch! You're creating a different metatable, another table and two
> different closures for every single instance. This is rather
Totally agreed, I only wrote it this way for benchmarking purposes.
Since my benchmark only created one message I didn't worry about
sharing the per-message-type overhead, but the real thing will most
certainly do this.
> Instead create the userdata from C code and keep the cdata _inside_
> the userdata. Cast the userdata to a pointer to your struct before
> using it: http://lua-users.org/lists/lua-l/2011-01/msg01282.html
That's perfect! With that approach I can make my actual objects a
userdata (and be able to use metamethods like __gc without waiting for
LuaJIT 2.1), but still use ffi for fast read/write of the data.
> > It turns out that table lookup inside __newindex is basically free, as are
> > both of the function calls: in my benchmark calling "wrapped.a = 5" was
> > just as efficient as calling the cdata cirectly! The generated assembly is
> > longer, but it runs at the same speed. Amazing.
> Because dead-store-elimination hits and turns your code into an
> empty loop.
Does it? I saw this store of my value (5) in the generated code -- I know
it's my value because when I change in in my Lua program, it changes in
the disassembly also:
1390bffd6 mov dword [rax+0xc], 0x5
Do you have any comment about whether the table lookup inside my
__newindex method can be JIT-ted as well as my benchmark implied?
Is that approach inherently more expensive than a regular method call?