# Python JIT not yet fast
**URL:** https://discourse.julialang.org/t/python-jit-not-yet-fast/130606
**Category:** Offtopic
**Created:** [July 10, 2025, 12:55pm UTC](https://discourse.julialang.org/t/python-jit-not-yet-fast/130606 "2025-07-10T12:55:16Z")
**Posts on this page:** 11
**Page:** 1
### Author:  [@sylvaticus](https://discourse.julialang.org/u/sylvaticus)
#### Post date: [July 10, 2025, 12:55pm UTC](https://discourse.julialang.org/t/python-jit-not-yet-fast/130606/1 "2025-07-10T12:55:16Z")
Python JIT not yet fast:
> **[Despite 30 months work, core developer says Python's JIT compiler is often...](https://devclass.com/2025/07/09/despite-30-months-work-core-developer-says-pythons-jit-compiler-is-often-slower-than-the-interpreter/)**
>
> Ken Jin, a CPython core developer who works on the experimental JIT (just in time) compiler optimizer, says \[…\]
---
### Author:  [@juliohm](https://discourse.julialang.org/u/juliohm)
#### Post date: [July 10, 2025, 1:07pm UTC](https://discourse.julialang.org/t/python-jit-not-yet-fast/130606/2 "2025-07-10T13:07:36Z")
If only this huge work to try to make Python faster was redirected to Julia… 😮💨
It is beyond sanity really.
---
### Author:  [@croberts](https://discourse.julialang.org/u/croberts)
#### Post date: [July 10, 2025, 2:12pm UTC](https://discourse.julialang.org/t/python-jit-not-yet-fast/130606/3 "2025-07-10T14:12:55Z")
I’m anticipating that things downstream of a polished juliac small binary compiler will substitute for a python jit compiler. If so, then effort currently expended on making python faster will instead shift into efforts on better julia integration into python and efforts on julia itself. Of course, in the long run, as python programmers write an increasing fraction of their code in julia, many will conclude that it is better to skip python entirely.
---
### Author:  [@jling](https://discourse.julialang.org/u/jling)
#### Post date: [July 10, 2025, 2:36pm UTC](https://discourse.julialang.org/t/python-jit-not-yet-fast/130606/4 "2025-07-10T14:36:07Z")
But if you read what Ken Jin writes, it sounds like they’re optimistic
> **[Reflections on 2 years of CPython’s JIT Compiler: The good, the bad, the ugly](https://fidget-spinner.github.io/posts/jit-reflections.html)**
>
> My personal blog
---
### Author:  [@oscarvdvelde](https://discourse.julialang.org/u/oscarvdvelde)
#### Post date: [July 10, 2025, 3:04pm UTC](https://discourse.julialang.org/t/python-jit-not-yet-fast/130606/5 "2025-07-10T15:04:32Z")
How does this compare to Numba JIT?
My colleagues who work in Python often bring up Numba, reducing their need to consider Julia for speed.
Also, in Julia, we usually omit the compilation time when talking about performance. But if comparing their JIT against Python interpreted code, perhaps they consider it. Does their JIT always recompile at every command?
---
### Author:  [@jling](https://discourse.julialang.org/u/jling)
#### Post date: [July 10, 2025, 3:15pm UTC](https://discourse.julialang.org/t/python-jit-not-yet-fast/130606/6 "2025-07-10T15:15:10Z")
> [@oscarvdvelde](#):
>
> My colleagues who work in Python often bring up Numba, reducing their need to consider Julia for speed.
surprised they’re not on Jax train yet
---
### Author:  [@stevengj](https://discourse.julialang.org/u/stevengj)
#### Post date: [July 10, 2025, 3:41pm UTC](https://discourse.julialang.org/t/python-jit-not-yet-fast/130606/7 "2025-07-10T15:41:18Z")
This kind of topic has come up many, many times already.
See many previous discussions of this topic linked in [JIT Compiler for CPython - #4 by stevengj](https://discourse.julialang.org/t/jit-compiler-for-cpython/108055/4) e.g. why previous attempts at a Python JIT compiler failed: [Julia motivation: why weren't Numpy, Scipy, Numba, good enough? - #3 by kristoffer.carlsson](https://discourse.julialang.org/t/julia-motivation-why-werent-numpy-scipy-numba-good-enough/2236/3)
---
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [July 10, 2025, 5:22pm UTC](https://discourse.julialang.org/t/python-jit-not-yet-fast/130606/8 "2025-07-10T17:22:19Z")
> [@oscarvdvelde](#):
>
> reducing their need to consider Julia for speed.
According to my experience, Julia is at least 5 times faster then Numba. And much more readable and maintainable. Reasons: Call overhead for Numba functions vs inlining of small functions in Julia, but also features like StaticArrays that can give a nice speed improvement not available in Numba.
---
### Author:  [@lewis](https://discourse.julialang.org/u/lewis)
#### Post date: [July 10, 2025, 6:51pm UTC](https://discourse.julialang.org/t/python-jit-not-yet-fast/130606/9 "2025-07-10T18:51:40Z")
I’d rather have an AOT compiler, realizing this is hard because of some truly dynamic Julia features that postpone compilation of some methods until there is a call for such methods. Maybe AOT would only compile methods that are dispatchable to based on method signatures in the source. Probably I don’t understand the complexities. But, cpython has so many years of relying on putting more stuff into their runtime and allowing more untyped variable references that it’s just a lot harder. We already have a pretty great JIT for Julia so let’s cheer for AOT.
---
### Author:  [@jling](https://discourse.julialang.org/u/jling)
#### Post date: [July 10, 2025, 7:34pm UTC](https://discourse.julialang.org/t/python-jit-not-yet-fast/130606/10 "2025-07-10T19:34:27Z")
> [@lewis](#):
>
> AOT would only compile methods that are dispatchable to based on method signatures in the source.
That’s kind what the `juliac.jl --experimental --trim` try to do – it try to start with the entry signature (say, you have `@ccallable` interface, then the entry point types are concrete and static), and trace out what methods need to be compiled.
---
### Author:  [@Alfredo](https://discourse.julialang.org/u/Alfredo)
#### Post date: [August 7, 2025, 4:20am UTC](https://discourse.julialang.org/t/python-jit-not-yet-fast/130606/12 "2025-08-07T04:20:04Z")
This post was temporarily hidden by the community for possibly being off-topic, unfocused, inappropriate, or spammy.