Re: Design questions for a small s-expression library

[Philipp Janda <siffiejoe@...>]

Am 22.01.2014 08:29 schröbte Antonio Vieiro:
> El 21/01/14 10:24, lua-l-request@lists.lua.org escribió:
> > Date: Mon, 20 Jan 2014 10:56:54 -0200
> > From: Elias Barrionovo <elias.tandel@gmail.com>
> > Subject: Re: Design questions for a small s-expression library
> > To: Lua mailing list <lua-l@lists.lua.org>
> >
> > On Jan 18, 2014 12:05 PM, "Antonio Vieiro" <antonio@antonioshome.net>
> > wrote:
> > > 3. LuaJIT will be as performant in approach B (invoking C functions for
> > "car", "cdr", etc.) as in approach A (using Lua native code).
> >
> > Not really, since the "classic" C API aborts LuaJIT traces, while
> > plain Lua
> > is properly JITted (except for a few builtins, such as next()).
>
> Yep, I imagine I would have to use the LuaJIT FFI library.
>
> Anyway the "in C" approach proved to be a pain in the neck from the
> memory management point of view. Plain Lua is not doing bad.

Btw., the closure approach could also be implemented in C and would 
consume even less memory than the other approaches:

Lua 5.1 C closure-based:  72
Lua 5.2 C closure-based:  64
LuaJIT C closure-based:   48

The remark about aborted traces in LuaJIT is still true, although I've 
heard that the latest LuaJIT can trace "around" C API calls. Not sure if 
FFI can help in case you want to store arbitrary Lua values ...


> Thanks,
> Antonio

Philipp