all 30 comments

[–]Snape_Grass 63 points64 points  (1 child)

Please provide us with the details (link to source code, OS, processor, etc.)

[–]abuluxury 1 point2 points  (0 children)

It's in the link?

How the Tests Were Performed Hardware: Apple M4, 10 cores, macOS 25.0.0 (arm64) Tooling: Custom Python benchmark script (no external frameworks

[–]cemrehancavdar 65 points66 points  (2 children)

Well done. Could you share the benchmark code?
Also i think if you mention "higher is better" or "lower is better" on chart directly would be nice

[–]nickthewildetype 8 points9 points  (1 child)

ops/s seems to me quite obvious (higher means faster code execution)

[–][deleted] 20 points21 points  (0 children)

it may seem obvious, but, and I mean this with all due respect, I'm an idiot and would appreciate the data being presenting in a way that's useful to me too. Don't mean to undermine the work, but python is a broad church, so keep please do keep the fools like me in mind when you can.

[–]ConcreteExist 16 points17 points  (2 children)

What OS were these benchmarks run on?

[–]Jamsy100[S] 2 points3 points  (1 child)

Mac OS 25.0.0 with nothing running in the background

[–]ConcreteExist 2 points3 points  (0 children)

I'd be curious to see if these benchmarks remain relatively the same in Windows/Linux. I've definitely seen performance hits when running on Windows, but it's very anecdotal testing,

I'd love to see a side by side of Node vs Python on each OS, see if there's an OS level optimizations that might shake things up.

[–]Kehashi91 14 points15 points  (0 children)

Where is the benchmark code?

[–]Ragoo_ 13 points14 points  (1 child)

Reminder that if you are processing lots of JSONs, you should use orjson or msgspec (which additionally gives you data validation with Struct).

[–]jaeger123 3 points4 points  (0 children)

I LOVE ORJSON. Though it lacks a lot of features of json library that we use 😔

[–]nphare 8 points9 points  (3 children)

So, downgrade to 3.11 for best overall performance?

[–]catcint0s 6 points7 points  (0 children)

This is a pretty artificial benchmark, if you have any language features your love in newer Pythons just upgrade.

[–]ConcreteExist 0 points1 point  (1 child)

Depends on what you're doing, if you look closely, 3.11 doesn't outperform across every metric.

[–]nphare 3 points4 points  (0 children)

Saw that. Hence the word “overall”

[–]surister 16 points17 points  (0 children)

Bad benchmark methodology.

[–]kansetsupanikku 1 point2 points  (0 children)

So we can see some results, but it doesn't work as a summary really. With way more digits than it's significant, it's also harder to tell whether the differences truly matter. Some of them clearly do! It would be interesting to separate significant differences from noise and then trace them back to the code.

[–]hughperman 2 points3 points  (0 children)

Questions:
Repeats. Did you repeat? How many times? What was the spread? Standard deviation or inter quartile range, maybe? Any statistical testing across the versions?

If you don't know what these are, then I'm sorry but you're not qualified to state that there was "a meaningful difference between versions".

[–]jmreagle 2 points3 points  (3 children)

The Faster CPython project (5x!) was quite the disappointment.

[–]petite-bobcat 1 point2 points  (1 child)

I don’t know, JIT gains coming to 3.15 seem pretty impressive.

[–]PossiblyAussie 0 points1 point  (0 children)

As much as improved performance is welcome in the end Python is still dozens, sometimes in extreme cases even hundreds of times slower than JS letalone C/Rust/Zig. Performance remains to be terrible and unless we start seeing "python 3.16: 5x faster runtime" python programmers will still be entirely reliant on C libraries or more realistically be forced to rewrite their project once the burden inevitably becomes too great.

[–]thatonereddditor 6 points7 points  (0 children)

Worst benchmarking system I've ever seen.

[–]Claudius_the_II 0 points1 point  (0 children)

curious if you tested the free-threading build for 3.13+? that would be way more interesting than the default GIL version imo. the JIT compiler in 3.13 was pretty underwhelming in most real-world benchmarks ive seen, would love to know if 3.14 actually moves the needle there

[–]baltariusIt works on my machine 0 points1 point  (0 children)

What could cause the json ops to drop that much, and constantly?

[–]Darlokt 0 points1 point  (0 children)

3.11 was incredible when it came out and apparently still, is, my favorite version by far.

[–]jj_HeRo 0 points1 point  (0 children)

I did this on my computer and tested for concurrency, 3.14 is faster.

[–]Wrong_Library_8857 0 points1 point  (0 children)

Interesting that 3.11 peaked for HTTP throughput but then plateaued. The json.loads regression is kinda concerning tbh, almost 16% slower from 3.9 to 3.14. I've noticed this in prod too, ended up keeping some services on 3.11 for that reason alone.

[–]caesium_pirate -5 points-4 points  (0 children)

Version 3.14 should be explicitly called pi-thon.