Python performance optimization: what techniques actually matter at scale?

I am looking for real-world advice on Python performance bottlenecks beyond the obvious ones like using list comprehensions instead of loops. Specifically, I would value insights into: when is C extensions/Cython worth the complexity overhead; which libraries provide genuine speedups for numerical operations versus just convenience abstractions; and whether asyncio's cooperative multitasking truly scales as advertised for I/O-bound applications with thousands of concurrent connections. The responses should include concrete examples where possible rather than vague generalizations about 'writing efficient code.'

The hierarchy of impact, in order:

1. Algorithmic complexity (O) — The only optimization that scales with data volume. Reducing O(N^2) to O(N log N) wins you orders of magnitude; no micro-optimization can compete. This is where 90% of performance gains come from at scale.

2. I/O and concurrency — Network calls, disk reads, and database queries are the real bottlenecks in most applications. Parallelize with asyncio or threading for I/O bound work, use batch inserts instead of N individual writes, cache aggressively (Redis/memcached). A single Redis GET replaces repeated O(N) computations.

3. Data structures — Choosing a set over a list for membership tests turns O(N) into O(1). Using collections.deque for FIFO queues avoids the O(N) cost of list.pop(0). These are constant-time wins that compound

The hierarchy of impact usually goes in this order, which is the inverse of what people try first:

1. Algorithmic complexity — O(n^2) to O(n log n). No micro-optimization beats a better algorithm at scale. Profile with cProfile before changing anything; 90% of bottlenecks are dominated by one or two hot functions.
2. I/O and concurrency — the wall clock is usually bound by database queries, network calls, or disk access, not CPU cycles. Use asyncio for high-concurrency I/O, multiprocessing for CPU-bound tasks (bypasses the GIL), and batch your DB operations to reduce roundtrips.
3. Data structures — using a set lookup instead of list membership turns O(n) into O(1). Using defaultdict saves boilerplate and prevents common KeyError bugs. These are compounding wins across millions of iterations.
4. Vectorization with NumPy/Pandas — when you have numerical arrays

I'm going to push back on everything in this thread because the framing itself is a category error. "What matters at scale" smuggles in an assumption that there exists a single architecture or stack where optimization decisions are meaningful, which isn't true for Python projects.

First, the split between "algorithmic optimizations" and "runtime performance techniques" is artificial. If your O(n^2) bottleneck can be solved with numpy vectorization, you haven't optimized the runtime — you've changed the asymptotic complexity by pushing a loop into C. The thread treats these as separate buckets but they merge at every interesting junction.

Second, "what matters" depends entirely on which scale we mean. For high-frequency trading signals, it's Cython + shared memory buffers + avoiding GIL contention in the hot path. For data pipelines processing TBs/day, it's multiprocessing over batch windows and avoiding object deserialization overhead at each step. For a web service under load, it's async I/O saturation points and connection pool sizing. The advice that works for one of those is actively harmful to the others.

Third — this is where most people get it wrong — Python performance discussion almost always

The real answer is that 95% of "optimization" is just profiling to find where the actual bottleneck lives, and then doing nothing if that doesn't matter. I saw a team rewrite their entire data processing pipeline in C++ last year because someone benchmarked one function with Noloop(N) vs Numpy operations and got spooked by the numbers — but they hadn't actually measured whether it saved them money or time at their actual scale, which turned out to be about 4 hours a month.

For stuff that genuinely needs tuning: check Cython for tight loops over large arrays (still Python syntax mostly), use uvloop instead of asyncio if you're IO-bound on network services, and look into pol

Numpy vectorization is the one that pays off most consistently.