Javier Guerra Giraldez <javier@guerrag.com> writes:
On Jun 21, 2012 5:33 PM, "Miles Bader" <miles@gnu.org> wrote:
The FFI interface is not a good fit for ordinary Lua, because it's too
dynamic (too much stuff happens at runtime), and as a result, too slow.
In LuaJIT, this isn't an issue because LuaJIT can compile everything at
runtime, but Lua can't do that.
My guess (or hope ) is that a sophisticated library could compile the FFI
input to a separate VM that manages the Lua /C interface, just like LPEG
does, a specialized VM to do the pattern matching.
Of course, to make it fast enough we need another Roberto or Mike.....
Well to be fair, my previous statement ("it will be too slow") isn't
based on any actual _data_, so take it with a grain of salt. I may
simply be wrong about the speed.
One issue with benchmarking is that the FFI package is pretty complex,
so what's fast and what's not is going to depend a lot on exactly how
it's used.
To get a bit better idea I tried the a simple benchmark that just
calls "strcmp" a bunch of times (on varying strings) in a loop. I
then wrote an equivalent "classic Lua C module", and tried that
too. I imagine this mostly measures the speed of the argument
marshalling etc in LuaFFI.
In this simple test LuaFFI didn't do too bad; the "classic Lua C
module" version is only about three times as fast as the "LuaFFI"
version (in LuaJIT, of course, the FFI benchmark is about 10 times
faster than the "classic Lua C module").
Nonetheless, I think more core support would be necessary to get
around the portability issues (if that's even possible, though my
guess it is for at least some reasonable subset of the functionality).
-miles
