Re: Question about accessing Lua tables and arrays faster

[Coda Highland <chighland@...>]

On Thu, Jul 25, 2013 at 8:50 AM, Leo Romanoff <romixlev@yahoo.com> wrote:
> - But when going more and more into "native" performance domain, you notice that some optimizations optimizations are missing or impossible due to Lua semantics. Since LuaJIT tries to be as compliant as possible to Lua specification, it cannot perform certain kind of optimizations, I guess, because it would break Lua's semantics. Moreover, LuaJIT probably does not want to diverge too far away from Lua, even if it could. Because it would essentially result in a new incompatible language or a new incompatible set of libraries. Therefore, IMHO, any changes that affect the language (data types, public interfaces for C integration, public interfaces for GC integration (should they exist), etc) should be agreed between Lua and LuaJIT. Any changes in these parts should happen on both sides to keep Lua uniform.

LuaJIT already does this, via its FFI -- a language extension Lua
doesn't have (unless you count the LuaFFI module, which is good for
compatibility but not so much for speed). One typical LuaJIT
optimization trick is to define an FFI struct with statically-typed
fields even if you're not going to ever interface it with C code,
because it gives you the predefined offsets and data types you were
thinking about, which improves performance.

Code written this way, however, doesn't work in Lua anymore.

/s/ Adam