Performance: profiling, vectorising and when to leave Python

Python is slow per operation and fast to write, which makes it right for research and wrong for a hot path. Making research code fast is almost entirely about moving the loop out of the interpreter; the decision to leave Python altogether is a different question with a much higher bar.

Proposition 6.1

Measure before you optimise

Intuition about where time goes is unreliable, and the cost of being wrong is optimising code that was never the bottleneck. Profile, find the dominant cost, fix that, and profile again — because the second bottleneck is rarely where you expected after the first is gone.

Holds when

cProfile for function-level costs; line_profiler when you need the line.
memory_profiler or tracemalloc when the problem is memory rather than time.
%timeit for microbenchmarks, and beware of caching effects that make the second run unrepresentative.

Step	Typical gain	Cost to you
Fix the algorithm	Unbounded	Thinking
Vectorise with NumPy	10–100 $\times$	Rewriting the loop
Avoid repeated allocation	2–5 $\times$	Preallocate and use `out=`
`numba` on a numeric loop	10–100 $\times$	A decorator, and a compile step
Multiprocessing	Number of cores	Serialisation overhead
Rewrite in C++	2–10 $\times$ over good NumPy	A great deal

Table 6.2 · The speedup ladder. The top row dominates everything below it. An

O(n^2)

algorithm vectorised beautifully still loses to an

O(n\log n)

one written plainly, and the difference grows with the data.

Figure 6.3 · Why you profile before you optimise. Rewriting a tenth of the runtime in C gains you nine per cent, even if the rewrite is perfect. Amdahl’s law is the argument for the profiler: the question is never how slow a function is, it is what share of the total it holds.

Performance: profiling, vectorising and when to leave Python

After this lesson you should be able to

Measure before you optimise

The rest of this lesson is in Premium