lua-users home
lua-l archive

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

Sometimes FFI is the only reasonable way to do the things, slow or not.

For example already deployed application, and in the last minute you have to hook something, and you can't deploy other dlls.

Or application that is live and running. And plenty of others.

Any kind of communication should be minimized. Your example with strcmp() it's not something that would get used in practice.

For example calling million times glBegin()/glEnd() won't cut it even in OpenGL, hence you have to use glDrawArrays or something similar, where the data is prepared in an array.

Chatty communication kills you overall (ffi, network, sql, etc.).
Batch it, and you are done.

On 6/22/2012 1:54 AM, Miles Bader wrote:
Javier Guerra Giraldez <> writes:
On Jun 21, 2012 5:33 PM, "Miles Bader" <> 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).