|
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: 48The 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