Python Optimization Techniques

Optimization Starts With Measurement

Python optimization starts with a target, not with a trick. Decide what must improve: p95 latency, total runtime, peak memory, startup time, throughput, or cloud cost. Then measure the current behavior on input that looks like production.

The fastest-looking change is often irrelevant if it does not move the measured bottleneck. A better algorithm usually beats a micro-optimization. Removing a copy can matter more than changing a loop shape. Caching can be a win or a memory leak depending on the workload.

The Optimization Loop

The loop is deliberately boring: set a target, measure a baseline, profile, classify the bottleneck, change one thing, and re-measure. If the metric does not move, revert or keep the readability.

import cProfile
import pstats

def main():
    run_realistic_workload()

with cProfile.Profile() as profiler:
    main()

stats = pstats.Stats(profiler)
stats.strip_dirs().sort_stats("cumulative").print_stats(15)

cumulative time helps find call paths that cost the program time overall. tottime helps find functions whose own body is expensive.

Recipe 1: Find the Hot Path with cProfile

Use cProfile when the program is CPU-bound or when you need a first map of where time goes. Start at the top cumulative rows and read call counts before editing code.

import cProfile
import pstats

def profile_workload():
    rows = load_rows()
    return build_report(rows)

cProfile.runctx(
    "profile_workload()",
    globals(),
    locals(),
    "profile.stats",
)

stats = pstats.Stats("profile.stats")
stats.sort_stats("cumulative").print_stats(20)

If one function is called millions of times, reduce the call count or change the data structure before trying local-variable tricks.

Recipe 2: Fix Algorithm and Data-Structure Costs First

def has_user_linear(users, target_id):
    return any(user.id == target_id for user in users)

def index_users(users):
    return {user.id: user for user in users}

users_by_id = index_users(users)
user = users_by_id.get(target_id)

A dictionary lookup can remove repeated linear scans. The tradeoff is memory and index maintenance. Measure with representative sizes, because building the index can cost more than it saves for small inputs.

Recipe 3: Cache Repeated Pure Work

from functools import lru_cache

@lru_cache(maxsize=4096)
def parse_rule(rule_text):
    return compile_rule(rule_text)

result = parse_rule("status == 'active'")
print(parse_rule.cache_info())

lru_cache works best for deterministic functions with hashable arguments. Keep maxsize bounded unless you have a deliberate reason not to. Watch hit rate and memory growth with cache_info().

Recipe 4: Reduce Memory Pressure

import tracemalloc

tracemalloc.start()
result = run_workload()

current, peak = tracemalloc.get_traced_memory()
current_mib = current / 1024 / 1024
peak_mib = peak / 1024 / 1024
print(f"current={current_mib:.2f} MiB")
print(f"peak={peak_mib:.2f} MiB")

snapshot = tracemalloc.take_snapshot()

for stat in snapshot.statistics("lineno")[:10]:
    print(stat)

tracemalloc.stop()

When memory is the bottleneck, measure peak usage directly, then use snapshots for line-level follow-up. Look for large intermediate lists, repeated copies, unbounded caches, and many small objects. Generators, chunking, arrays, and __slots__ can help when they match the data shape.

Recipe 5: Move Numeric Hot Loops Out of Python

def python_sum_squares(values):
    total = 0
    for value in values:
        total += value * value
    return total

If profiling shows a numeric loop dominates, the fix is often to move the loop out of Python's per-item interpreter overhead: NumPy, vectorized libraries, Cython, Numba, Rust/C extensions, or a database/vector engine. Measure end-to-end, including conversion costs.

What CPython Already Optimizes

CPython already performs compile-time and runtime optimizations. Constant folding and unreachable-code simplifications can happen during compilation. Python 3.11 introduced a specializing adaptive interpreter described by PEP 659: frequently executed bytecode can be specialized based on observed runtime types.

Use dis when you need to inspect what the interpreter is doing:

import dis

def add(a, b):
    return a + b

for _ in range(20_000):
    add(1, 2)

dis.dis(
    add,
    adaptive=True,
    show_caches=True,
)

Treat specialization as a runtime implementation detail, not a promise that a specific function becomes a fixed percentage faster. For deeper mechanics, see Python Bytecode Compilation.

Common Pitfalls

Optimizing Without a Bottleneck

def clever(values):
    return list(
        map(
            lambda value: value * value,
            filter(lambda value: value % 2 == 0, values),
        )
    )

def clear(values):
    return [value * value for value in values if value % 2 == 0]

Prefer clear code until profiling shows the code is hot and the replacement is measurably better.

Caching Without Bounds

cache = {}

def get_user(user_id):
    if user_id not in cache:
        cache[user_id] = fetch_user(user_id)
    return cache[user_id]

Unbounded caches can turn a latency fix into a memory leak. Use bounded caches, explicit invalidation, or workload-specific retention rules.

Optimizing the Wrong Layer

A faster loop does not help when the real cost is a database query, network call, disk read, serialization step, or lock contention. Classify the bottleneck before choosing the technique.

Decision Table