PyPy, by contrast, emphasises raw speed, sacrificing various aspects of CPython's C/C++ interoperability in order to attain it. It's absolutely the implementation you want to be using if your main concern is the performance of your Python code in general, and there aren't any obvious hotspots that could be more selectively accelerated.

To date, the CPython model of "Use (C)Python to figure out what kind of problem you have, then rewrite your performance bottlenecks in a language more specifically tailored to that problem space" has proven relatively popular. There's likely still more we can do within CPython to make typical code faster without increasing the interpreter complexity too much (e.g. Yury's idea of introducing an implicit per-opcode result cache into the eval loop), but opt-in solutions that explicit give up some of Python's language level dynamism are always going to be able to do less work at runtime than typical Python code does.

Cheers,

Nick.

P.S. You may find https://www.curiousefficiency.org/posts/2015/10/languages-to-improve-your-python.html#broadening-our-horizons interesting in the context of considering some of the many factors other than raw speed that may influence people's choice of programming language. Similarly, https://www.curiousefficiency.org/posts/2017/10/considering-pythons-target-audience.html provides some additional info on the scope of Python's use cases (for the vast majority of which, "How many requests per second can I serve in a naive loop in a CPU bound process?" isn't a particularly relevant characteristic)

--