3 ms·

I'm a Python "snob", going on 24 years and If I ever "I care about performance and memory footprint" I'd not use Python. Python is good enough 90%. You get fas

I'm a Python "snob", going on 24 years and If I ever "I care about performance and memory footprint" I'd not use Python. Python is good enough 90%. You get faster 2x 10x, etc code by picking better algorythms or solutions. In Python, you should not be caring about 10% or 30% speed improvement. It's not worth it, It's not Python's strength. When you need faster you go to C based libs (the python libs that need to go fast are already in C), https://en.wikipedia.org/wiki/Cython https://en.wikipedia.org/wiki/Cython https://en.wikipedia.org/wiki/Numba https://en.wikipedia.org/wiki/Numba etc.

jerven 7y ago
Or go for [1]pypy or [2]graalpython. I know that equivalent code in graal java ee produces equivalent assembly/performance to C+current gcc, which really shows that yes changing to a JIT can pay off. The python in graalvm is early stages but it shows that the old lesson of just write the hot spot in C is no longer true. Chris Seaton shows that for Ruby/C the language Ruby interpreter/C switch is expensive. I think the same is true for Python interpreter/C switches. Something that GraalVM+Python|Ruby can optimize out. [1] https://www.pypy.org https://www.pypy.org [2] https://www.graalvm.org/docs/reference-manual/languages/python/ https://www.graalvm.org/docs/reference-manual/languages/pyth...
- jashmatthews 7y ago
  LuaJIT has great performance through the C FFI. It’s more that traditional JITs can’t optimize across FFI boundaries. Hopefully Chris will correct me if I’m full of shit. There are other approaches which can work too, like compiling C to LLVM IR using Clang so a function can be inlined by an LLVM based JIT at runtime.
edflsafoiewq 7y ago
Like with JS, you might not have a choice. I mostly use Python for extending programs that use it as a embedded scripting language. Performance is still important.

jerven 7y ago

Or go for [1]pypy or [2]graalpython. I know that equivalent code in graal java ee produces equivalent assembly/performance to C+current gcc, which really shows that yes changing to a JIT can pay off. The python in graalvm is early stages but it shows that the old lesson of just write the hot spot in C is no longer true. Chris Seaton shows that for Ruby/C the language Ruby interpreter/C switch is expensive. I think the same is true for Python interpreter/C switches. Something that GraalVM+Python|Ruby can optimize out. [1] https://www.pypy.org https://www.pypy.org [2] https://www.graalvm.org/docs/reference-manual/languages/python/ https://www.graalvm.org/docs/reference-manual/languages/pyth...

jashmatthews 7y ago
LuaJIT has great performance through the C FFI. It’s more that traditional JITs can’t optimize across FFI boundaries. Hopefully Chris will correct me if I’m full of shit. There are other approaches which can work too, like compiling C to LLVM IR using Clang so a function can be inlined by an LLVM based JIT at runtime.

edflsafoiewq 7y ago

Like with JS, you might not have a choice. I mostly use Python for extending programs that use it as a embedded scripting language. Performance is still important.