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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
