lua-users home
lua-l archive

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


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