Re: C binding strategy

  • From: Mike Pall <mike-1208@xxxxxxxxxx>
  • To: luajit@xxxxxxxxxxxxx
  • Date: Thu, 16 Aug 2012 12:29:05 +0200

Justin Cormack wrote:
> On Thu, Aug 16, 2012 at 8:12 AM, Francisco Tolmasky <tolmasky@xxxxxxxxx> 
> wrote:
> > Oh, I should have mentioned this: I am deploying on iOS so the fact that
> > jit-ing won't be an issue may change the answer(s) to this question.
> [...]
> Without the JIT you lose the advantage of compiling and inlining but
> the calls to C are also much slower. But actually accessing ffi
> structures in Lua and C should not be penalized at all I believe. The
> interpreter is still fast, so I am not sure it will change the
> strategy you use drastically.

Access to FFI structures on the Lua side ('x = p.x' or 'p.x = x')
is pretty slow without the JIT compiler. Slower than performing
the same operations on a plain Lua table.

OTOH creating and accessing Lua objects on the C side is much more
expensive than for the native data structures the FFI gives you.

[Also, you'll need a C function bound via the classic Lua/C API to
handle Lua tables and these calls are not JIT-compiled, unlike
their FFI counterparts. A very relevant point for most users that
are embracing the FFI, but irrelevant in an interpreter-only
context on IOS.]

And about those "in between" objects: consider not creating such
objects. Pass them around as individual elements. E.g. prefer
mouseUpdated(x, y) over mouseUpdated(Point). The first thing you'd
probably do in the mouseUpdated() function is to access the
coordinates, anyway.

IMHO the gain in abstraction by OO-ifying trivial aggregates for
isolated objects is overrated. OTOH you'll definitely want to use
FFI structures to pass around big arrays of points and to define
(Lua or native C) methods for them.


Other related posts: