LuaJIT - an alternative for current Python C bindings

[Florian Weimer]

On 11/15/2012 01:49 AM, Alek Paunov wrote:

> So, to me it seems natural joining all above together to start thinking
> for replacing the classic python C bindings with thin textual or
> bytecode(*) LuaJIT/FFI shims in benefit of things with great set of
> dependencies like Anaconda (thanks to lupa, Lua objects behaves like
> Python ones in Python). The result will be order of magnitude easier for
> maintenance (towards the APIs evolution) and faster code.

LuaJIT is currently not available for our secondary architectures, so 
this would need fixing first.  ("not available" meaning exactly that, 
there is no fallback to a slow C interpreter mode or something like that.)

It's also not clear how significant the actual memory savings will be 
because some of the Lua OO frameworks have quite a bit of overhead.  And 
the eventually arriving abrt plugin will bring some weight with it, too.

This is nothing against Lua or LuaJIT.  I just don't think that 
switching programming languages will magically reduce resource 
consumption.  This has to be an explicit design goal, or else it is not 
likely to happen.  I'm sure it's possible to write resource-conserving 
Python code, too.  It's just the baseline overhead from the run-time 
system which is unavoidable, but that's fairly small for Python 
(apparently less than 2 MB of unshared RSS per process).

-- 
Florian Weimer / Red Hat Product Security Team