Performance | PyPy

Optimization strategy
This document collects strategies, tactics and tricks for making your code run faster under PyPy. Many of these are also useful hints for stock Python and other languages. For contrast, we also describe some CPython (stock Python) optimizations that are not needed in PyPy.
As a general rule, when considering performance issues, follow these three points: first measure them (it is counter-productive to fight imaginary performance issues); then profile your code (it is useless to optimize the wrong parts). Only optimize then.
PyPy 2.6 introduced vmprof, a very-low-overhead statistical profiler. The standard, non-statistical cProfile is also supported, and can be enabled without turning off the JIT. We do recommend vmprof anyway because turning on cProfile can distort the result (sometimes massively, though hopefully this should not be too common).
These suggestions apply to all computer languages. They're here as reminders of things to try before any Python or PyPy-specific tweaking.
Before you start tuning, build a regression-test suite for your code. This front-loads a significant amount of work, but it means you can try lots of optimizations without worrying so much about introducing functional bugs.
Human beings are bad at guessing or intuiting where the hotspots in code are. Measure, don't guess; use a profiler to pin down the 20% of the code where the code is spending 80% of its time, then speed-tune that.
Measuring will save you a lot of effort wasted on tuning parts of the code that aren't actually bottlenecks.
As you tune, re-profile frequently so you can see how the hottest spots are shifting around.
Be aware of the difference between code that is compute-bound (slow because it's doing a huge number of instructions) and code that is I/O bound (slow because of disk or network delays).
Expect to get most of your gains from optimizing compute-bound code. It's usually (though not always) a sign that you're near the end of worthwhile tuning when profiling shows that the bulk of the application's time is spent on network and disk I/O.
Generally, when your code is doing things that are O(n**2) or larger in the size of your data set, the cost of those operations is going to swamp any small gains you can pick up with the tricks we describe here.
Tune your algorithms first. It's time to think about applying our list of micro-tuning tips after you think you've optimized out intrinsically expensive operations.
That said, be prepared for the possibility that you will discover better-hidden algorithmic problems as you micro-tune. Likely you will go through this cycle more than once.
It's extremely common for high time costs to lurk within some innocuous-looking code inside a tight loop - especially in code that does something like a searching/matching/lookup operation or any kind of graph traversal.
Probably the most common kind of performance-killer in compute-bound code is an O(n**2) operation that is disguised by being some sort of O(n) lookup or match inside an O(n) loop.
Another common time-sink is relatively expensive common-setup operations that are performed inside tight loops but could be moved to before they start. (For a representative case of this, see the micro-tuning tip on regexp compilation.)
Modern computers have multiple levels of memory caching, some directly on the processor chip. Causing a cache miss at any level incurs a performance penalty proportional to random-access time for the next outward (and much slower) layer of cache.
Accordingly, smaller is faster. Programs or routines with a small enough working set to fit inside a fast cache will be as fast as that cache is. To make your code fast, reduce the length of the series of Python or JIT-compiler opcodes it generates by making it simpler.
The tradeoff here is that algorithmic tuning often trades time for space - that is, it increases the size of an algorithm's working set by including pre-computations or tables or reverse maps in order to avoid O(n**2) operations.
It's impossible to predict in advance where the sweet spot in that tradeoff will be. You have to try different things and measure - which takes us right back to "Measure, don't guess". And another function of your regression test suite can be as a speed benchmark.
These are in no particular order.
Simple is better than complex. The PyPy JIT is not very smart; the simpler your code is the better it will run. Here again, though, you face a tradeoff: you may need to pay with more algorithmic complexity in order to avoid brute-force operations that are O(n**2) or worse.
Write plain-vanilla code in plain-vanilla ways. The PyPy JIT has many productions that optimize a common usage pattern against an uncommon usage pattern.
In CPython, global variables and functions (including package imports) are much more expensive to reference than locals; avoid them. (This is also good modularity practice).
The cost of CPython global references is high enough that, for example, if you have code in a frequently-visited inner loop that uses int() a lot, it may be worthwhile to create a local copy of the reference with "int = int" in an enclosing block.
However, this in not true in JITted PyPy code. The "int = int" hack won't buy you performance, it's just an extra copy. The modularity reason for avoiding globals are still valid.
Regular-expression compilation is expensive. If the regexp pattern in a search, match, or replace operation is static (doesn't mutate at runtime) refactor so it's only done once.
If the regexp compilation is in a class method, consider doing it as the initializer of a regexp-valued static (shared) class member and using that class member in your operation.
If the regexp compilation is in a free function, consider moving it to module level and referencing the resulting regexp object (but see the warning above about global variables).
New-style classes allow faster attribute access and take up less core per instance than old-style cl