I'm not going to outright call this "cheating", but most of the time, virtually unconditionally, when Python is fast it's because it isn't Python, it's C.
It definitely feels worth noting that Python is radically slower than other languages, and the main "tool" it provides for improving performance is to rely on another language entirely.
But I don't disagree that the Python owe's it's performance to C.. it owes everything to C :)
What do you mean? "Mean" with no qualification usually denotes arithmetic average (or mean).
For benchmarks much better option would be geometric mean. Because the relation of the results values not the difference.
Just because it isnt identical in implementation to the other languages doesn't mean its much simpler. Its fast because enough people cared to make it that way - it wasn't by some accident
Once you start working on that data using procedures actually written I python performance is usually far from stellar.
I have had that happen to me many times. Back in the guile 2.0 days I tried porting some utils to python based on preliminary benchmarks that were often an order of magnitude faster than my guile ones, but when the logic was implemented the difference was gone. Then guile 2.2 (and now guile 3) happened and everything got magically faster, even though less and less of the runtime is written in C.
> A naive Python script that loops over all needles and calls str.find in a loop to find all matches.
> working through all 3.5 gigabytes of test data once
> Time is ~6.5s.
I love these kinds of benchmarks. They consistently show that for specialised cases you do need to drop down to C/Rust/hand-written Haskell implementations. In many-many more cases, well, even Python with a naive implementation is good enough.
Not to diss Haskell or Rust. Only saying: chose your tools as you see fit, and benchmark.
Also kudos to the authors to use mean instead of average in the graphs.