Re: LuaJIT - an alternative for current Python C bindings
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