Will Removing Python’s GIL make it significantly faster?
Date: 2025-07-09 | build | create | python | tech |
I recently came across a discussion about Python's 7 year plan to remove its GIL (Global Interpreter Lock) and the impact it would have on the language. The GIL has long been cited as a blocker for performance improvement in Python so if it could make Python significantly faster, it could change how we view the language and what tasks it's suited for.
I personally like to keep tabs on programming language perf as I use it as a factor for choosing between languages. I mostly do backend so perf is not the most important thing but still something I like to consider.
So in this post we're going to explore that question - will removing Python's GIL make it significantly faster?
What is Python's GIL?
The GIL (Global Interpreter Lock) was created to solve thread safety in memory management.
Python uses reference counting for memory management (determining when memory can be garbage collected) and went with a single global lock to ensure no race conditions when updating reference counts.
This is relatively simple and relatively fast in single threaded programs so for many cases works well.
Python's GIL prevents true parallelism
The problem is that Python's GIL prevents true parallelism.
Most variable reads / updates involve the GIL (both shared and local variables!) as they may incur reference count changes which means Python code is constantly interacting with the GIL. This means that even when you spin up multiple threads in "parallel", those threads will constantly be using variables and thus waiting on the GIL for their turn to process.
This means that most threads in Python don't actually run in parallel but more sequentially which removes most of the benefit.
To get around this, you can spin up multiple processes instead as each process has its own GIL.
The drawbacks with this approach is it's harder to work with and processes don't typically share memory which can be a problem for data intensive apps like machine learning, scientific computing, and data processing - which is kind of where Python's ecosystem is king.
Example: Working with a 1GB dataset in memory, if you multiprocess to 4 processes it now takes up 4GB of memory which can be cost prohibitive depending on what you're working on.
The GIL problem doesn't affect all types of programs though, the GIL does get released in:
- IO operations (file reads, network requests)
- C extensions that explicitly release it (NumPy does this)
- Sleep / blocking calls (like waiting)
So while the GIL can be a major problem for larger parallel workloads, for many other workloads (like a web server) it's actually not a big deal.
Also quick call out that async / await runs with concurrency not parallelism so this can help a single thread do more stuff even when the GIL is in play (Async / Await is basically hey we're blocked on waiting on this thing here, let's go do some other work with the same thread in the meantime).
Will removing the GIL make Python significantly faster?
Python is ~2 years into its 7 year roadmap to remove the GIL so we can look at the early results to get an answer.
Early results say yes but it's workload dependent.
Where it's faster: well-designed parallel workloads
- 2-4x speedups in PageRank algorithm (codspeed)
- 10x improvements for some parallel file IO (backblaze)
Note that many libraries are not yet compatible with nogil and thus may require significant rewrites for users to benefit from these new features.
Where it's slower:
- 20% memory overhead for the additional locks nogil requires
- Single-threaded performance is 40% slower in Python 3.13 and 10% slower in 3.14
So GIL removal did unlock true multithreading in Python but it came with some baggage and likely won't speed up most general workloads without a lot of special attention.
Next
Python is not a fast language. Removing the GIL improves its performance in multithreading but so far does not appear like it's going to make a meaningful performance difference for most Python workloads.
So if you're looking for a performant language, Python probably isn't it. But it's still plenty fast enough for most usecases and most people choose it for how easy it is to read / write so still a solid choice if that matters to you (I personally rank Python as a B Tier language).
If you liked this post you might also like:
Want more like this?
The best way to support my work is to like / comment / share for the algorithm and subscribe for future updates.