r/programming • u/BestRef • 1d ago

Python 3.15 vs Python 3.14 – performance testing

https://en.lewoniewski.info/2026/python-3-14-vs-python-3-15-performance-testing/
278 Upvotes

93% Upvoted

57 comments sorted by

206

u/frostbaka 1d ago

This is huge, 1.15 speedup is not something we got for a long time

64

u/who_am_i_to_say_so 1d ago

Yeah any double digit gain is huge.

That could compound into dramatic speedups for some- especially any use case with bigints. I bet the number crunchers are celebrating!

29

u/frostbaka 1d ago

Imagine a win when you have 200 servers running a python app and then you get 30 for free?

11

u/PJBthefirst 1d ago

200 servers running a python app

Serious question, do people do this?

44

u/breadcodes 1d ago edited 1d ago

Serious answer, yeah. It's a valid language for backend code, with valid frameworks and libraries that are production ready, and they scale horizontally just fine. I worked on an app exactly like this description.

Though to be clear, most HTTP frameworks like Flask and Django use C interop libraries and very little time is actually spent on responding to requests in pure Python, and database round-trips are a bigger concern, so those ~200 servers aren't necessarily gaining anything.

This is actually a bigger deal for what I do now (Data Science) rather than backend code. That too uses C interop for most of it, but there's plenty of pure Python in the process.

11

u/frostbaka 1d ago

They actually do. Serving requests, sending requests, (de)serialization is alot of work. Business logic also takes time in the form of transformation, hot loops etc. etc. You can plug C on all hot paths but in a big codebase you still have a lot of python execution around.

11

u/Ythio 1d ago

Eve Online is an MMO with a python backend facing performance issues when there is more than 10000 players battling at the same location. They would absolutely love having extra headroom.

15

u/JanEric1 23h ago

Altough they are currently just migrating off python 2.7

2

u/Ythio 21h ago

Well let's see the half full glass, that's a lot of improvements coming up in the future

1

u/PJBthefirst 1d ago

That's very cool

5

u/Exepony 22h ago

You're asking if anyone has a Python backend...? Of course. OpenAI's API servers are all FastAPI, for example.

3

u/Serious-Regular 1d ago

all of IG's backend runs on django

6

u/XtremeGoose 1d ago

Of course. Reddit, for example, has most of its backend running in Python. You think it's not running (far) more than 200 instances?

-1

u/meneldal2 16h ago

I would hope most of the critical shit uses something faster being called from python at least

3

u/who_am_i_to_say_so 16h ago

It’s not critical but I have a Flask app that can serve 100k+ requests in a short time on one little server. I’m shocked at how able it is.

A lot of important functions in Python such as serving web requests are just C-based anyway. Most numpy and sci-py functions for the data munchers are C-bindings, too.

2

u/frostbaka 1d ago

We do, we have a pretty old Python codebase which is now running on modern stack but is still a huge monolyth serving lots of traffic, we are running almost 3 thousand pods on kubernetes with this monster, which translates into something like 400 VMs.

4

u/entronid 14h ago

is it? iirc they've been getting ~1.2x performance boosts every version since 3.10

2

u/frostbaka 14h ago

There was a slowdown in 3.14 release which was fixed some time after. 3.13 was 2-5% slower than 3.12 due to something new introduced and not sped up. There were ups and downs but a clear release boost was probably 3 releases ago

1

u/entronid 14h ago

really, i've seen benchmarks saying that 3.14 was decently faster

also i suppose 3.13 wasn't really a speedup because they were doing changes to prepare for JIT?

9

u/kachori8342 1d ago

15% is insane.

-7

u/xeow 1d ago edited 7h ago

It's certainly impressive, but let's be honest: it's not in any way insane. 10x would be insane.

11

u/ric2b 19h ago

On a language that is 30 years old and has been one of the top languages in terms of usage and investment for nearly 2 decades, a 15% improvement in a single release does seem insane.

1

u/xeow 11h ago edited 6h ago

It is absolutely and objectively not an "insane" improvement.

What happened with JavaScript over the years could legitimiately qualify as insane. That was a Herculean effort that improved the speed of JavaScript by 10x back in 2008. That's not +10%; that's 10x. Modern JS with V8, Crankshaft, TurboFan, and Maglev is 50x–200x faster for compute-heavy stuff compared to the original interpreters. Now that's insane.

So let's be truly honest, shall we?

+15% is a modest (but welcome!) incremental improvement. It's nice, and we should all be happy about it, but it's not a game-changer for Python like 10x was for JavaScript.

19

u/ApokatastasisPanton 1d ago

What explains the performance improvements?

23

u/amroamroamro 1d ago

probably the work done on the JIT

https://fidget-spinner.github.io/posts/jit-on-track.html

17

u/fatoms 23h ago

Release changes

The official Windows 64-bit binaries now use the tail-calling interpreter:

64-bit builds using Visual Studio 2026 (MSVC 18) may now use the new tail-calling interpreter. Results on Visual Studio 18.1.1 report between 15-20% speedup on the geometric mean of pyperformance on Windows x86-64 over the switch-case interpreter on an AMD Ryzen 7 5800X. We have observed speedups ranging from 14% for large pure-Python libraries to 40% for long-running small pure-Python scripts on Windows. This was made possible by a new feature introduced in MSVC 18, which the official Windows 64-bit binaries on python.org now use. (Contributed by Chris Eibl, Ken Jin, and Brandt Bucher in gh-143068. Special thanks to Steve Dower, and the MSVC team including Hulon Jenkins.)

AFAIK the JIT is still experimental and you need opt in, the new tail-calling interpreter is the more likely 'culprit' here.

10

u/l86rj 23h ago

So that 15% boost is only for windows? 

-9

u/svth 14h ago

Who gives a shit about the performance on Windows?

4

u/Leliana403 14h ago

Anyone trying to work out why the numbers in a performance thread moved, which is what the comment you replied to was explaining. Nobody asked you to run it.

73

u/boat-la-fds 1d ago edited 1d ago

Windows seems to be kind of an odd choice for this given most python code runs on Linux when ran in servers and I would guess that the combined market share of python developers on Linux and Mac far outweighs the one for Windows (I might even argue that we could exclude students since they generally don't have performance problems). I might even add that with managed services like Databricks for instance or with people on Windows that use WSL, even Windows users end up running their python on Linux

56

u/HrHagen 1d ago

This developer survery shows that development on Windows and Linux is about equal: https://lp.jetbrains.com/python-developers-survey-2024/

Sure the server market is likely to be dominated by Linux. But I think you are underestimating how many people work under Windows. Company software will be mostly under Windows.

48

u/CrowdGoesWildWoooo 1d ago

I mean he’s got a point. It’s only developed on windows, but would be installed on linux server. The performance benchmark is therefore less useful because that’s not how your prod looks like.

2

u/HrHagen 1d ago

Sure, but OC sounds like Windows is an unimportant platform. It surely is much more important than MacOS... I mean Windows is >75% on desktop (Linux 5% btw.). So software that is running on a desktop machine needs to run well under Windows. Not every python program is a web application.

8

u/CrowdGoesWildWoooo 1d ago

He’s pointing out it’s an odd choice to showcase benchmark.

Doing perf like this for a marginal improvement on development platform, is not particularly impactful. You wouldn’t be able to tell if your pandas runs 3.3s or 3.6s, but in servers that extra bit of performance improvement matters.

1

u/PaintItPurple 1d ago

The percentage of Python programs that are desktop software that run on Windows has to be less than the MacOS share of the total computer market.

1

u/KarnuRarnu 1d ago

I can't seem to read that on mobile, but picking jetbrains I'd expect a heavy bias toward windows already. 

2

u/meneldal2 16h ago

I often run the same script on both Windows and Linux

Windows is practical when you can have office opened at the same time as you fix the excel file you feed in my terrible script.

Still better than vba and it allows running it on headless Linux easily

1

u/PJBthefirst 1d ago

I have WSL but I don't default to it just to use Python, uv works just fine on Windows

4

u/HAK_HAK_HAK 1d ago

Wish it was less of a PITA to upgrade from one version to another in python. Dotnet just works TM 9/10 times and you get speed ups.

12

u/thomas_m_k 21h ago

I think the last really breaking change was in Python 3.7 where async became a keyword? After that, some old standard library modules were removed and there was the typical deprecation cycle of some methods and parameters, but I don't think Python is worse there than other languages.

Or are you talking about the fact that C extensions need to be recompiled for each new version? Even that can often be avoided nowadays thanks to the stable ABI.

1

u/HommeMusical 16h ago

My guess is that they are trying to update the system Python!

3

u/thomas_m_k 16h ago

Oh, that makes more sense! Yeah, I've just given up on that and use uv.

3

u/syklemil 22h ago

The Rust system where they cordon off breaking changes into Editions and you can keep using old editions with newer compiler versions, and doing crater runs (compiling everything on crates.io) to ensure compatibility is nice too.

That said, at least dealing with various versions of things in Python feels a lot smoother with uv.

1

u/HommeMusical 16h ago

Wish it was less of a PITA to upgrade from one version to another in python.

I've simply never encountered this.

Can you give an example?

Now, I hope you aren't trying to upgrade your system Python. Do not do that! Just leave it alone.

Also, I hope you aren't trying to replace older versions of Python with newer ones. Don't do that either.

I have Python 2.6, 2.7, 3.6, 3.7, 3.8, 3.9, 3.10, 3.11, 3.12, 3.13, 3.14, and 3.15 installed on this machine, though I never expect to use about half of them again.

2

u/Eternal_Atom 16h ago

We went from 3.8 to 3.12 in my work. It wasn't a huge huge hassle.

But we had many packages pinned for 3.8 compatibility. The drift between when those packages dropped support for 3.8 and where they are now was pretty different and caused more than 1 fully breaking change. So validation wasn't easy of just bump python all done.

That and we also had some internal clients still using 3.8 so we couldn't make full use of the new Types during transition was annoying too.

1

u/HommeMusical 16h ago

Aha, got it!

Sure, if you have a specific program with badly pinned packages, and there are indeed a lot of badly pinned packages that are still in use, then this will be an issue.

Node handles this in a maybe better but someone what different way - each package gets its own copy of its dependencies by default.

It works because most .js packages are small and texty.

But installing a new version of Python itself is usually trivial.

1

u/HAK_HAK_HAK 15h ago

This is it pretty much. You have production software that depends on twelve dependencies who introduce breaking changes on python version changes, which makes upgrading from 3.12 (or whatever) -> 3.15 a big hassle.

This is not an issue in dotnet because external dlls can continue targeting older versions than the developed software itself, so each can have its own upgrade cycle in isolation.

1

u/puzzlerninja 16h ago

I wonder how it handles thread safety and concurrency. Did they remove the Global Interpreter Lock? If yes, does that place the burden of ensuring concurrency correctness, on users of Python?

1

u/Murky-Relation481 7h ago

I believe they have GIL and no-GIL distros still. If you use python threads and rely on the concurrency it provides via the GIL you can still use that.

1

u/brucedawson 7h ago

I think that using "1.5x faster" to mean 33% less time is incorrect. I think that the clearer phrasing is "1.5x as fast." I talk about the language we use to describe performance improvements here: https://randomascii.wordpress.com/2018/02/04/what-we-talk-about-when-we-talk-about-performance/

-5

u/grady_vuckovic 15h ago

Isn't python like 100x slower than native code though? A 15% speed bump is certainly great but was anyone writing performance sensitive code in python anyway?

5

u/usrlibshare 14h ago

Do we really need to have this conversation over and over again?

Yes, people do. Sometimes, the "performance critical" operations are not critical enoug towarrant wroting in a native language. And speedups of orchestrating code are always worthwile.

5

u/entronid 14h ago

sure, but 15% more speed might translate to 5% more requests per second for a webapp or something

2

u/webu 15h ago

Probably a lot more than there should be.

But the true gain is that my macbook will save a few milliseconds when running vibed Python code to update my google calendar /s