You're off by at least an order of magnitude, and a very common class of performance problems that exists in any language is copying and allocating memory. Python is no different, and there are plenty of facilities to address that and other normal performance issues. If you're talking strictly about CPU bound performance problems, that's a bit of a red herring considering there is an entire ecosystem of Python tools to write performant CPU bound code.
A little late to reply, but you're of course right, there's no direct way to compare the performance. Python serves (among others) a niche, where it's basically the glue between highly optimized C libraries like numpy. If you're writing that kind of CPU bound code, Python just passes blocks of memory around and it's fine for that. I think this is what you're talking about.
I think outside of that niche, though, there are places where people are writing heavily CPU bound code in Python, because it is so easy to become CPU bound. Case in point: I recently sped up an ML ingestion pipeline by multiple thousands of percent by switching from a pure-python PDF library to one that wraps a .so written in C.
So my point, restated: if you're CPU bound in pure Python code and you have time to try and optimize it, just rewrite the critical section in C and use the FFI. This is how 90% of "Python" libraries get implemented anyway. Compared to this, trying to make Python code more CPU efficient is a waste of time.
By the way, I have done work on CPU performance optimizations in Go, Rust and C, and the things you'd typically do are not possible in Python anyway. You're basically left with randomly tweaking the code until the benchmark gives a thumbs up, because it hit on some cpython idiosyncrasy that will completely change around a few versions later.
