Optimization

What we're doing: Measure a real speedup from lru_cache on recursive Fibonacci, where naive recursion recomputes the same values exponentially many times.

import time
from functools import lru_cache

def fib_uncached(n):
    if n < 2:
        return n
    return fib_uncached(n - 1) + fib_uncached(n - 2)

@lru_cache(maxsize=None)
def fib_cached(n):
    if n < 2:
        return n
    return fib_cached(n - 1) + fib_cached(n - 2)

start = time.perf_counter()
fib_uncached(28)
t1 = time.perf_counter() - start

start = time.perf_counter()
fib_cached(28)
t2 = time.perf_counter() - start

print(f"uncached: {t1:.4f}s")
print(f"cached:   {t2:.6f}s")
print(f"speedup: {t1 / t2:.0f}x")

1

The uncached version recomputes fib(n-2) millions of times across the recursive call tree — genuinely exponential work.

3

@lru_cache means every distinct n is computed exactly once — the second call with the same n returns instantly from the cache.

uncached: 0.0648s
cached:   0.000175s
speedup: 370x

Why this works: Naive recursive Fibonacci recomputes the same sub-values an exponential number of times — fib(28) alone makes over a million redundant calls. Caching turns it into linear work: each distinct n computed exactly once, which is the direct, measured source of the 370x speedup.

What we're doing: Simulate the round-trip cost difference between N separate calls and one batched call, using a fixed per-call overhead to make the pattern concrete.

import time

ROUND_TRIP_OVERHEAD = 0.001   # simulated fixed cost per network call

def fetch_one(item_id):
    time.sleep(ROUND_TRIP_OVERHEAD)   # stands in for a real network round trip
    return {"id": item_id}

def fetch_batched(item_ids):
    time.sleep(ROUND_TRIP_OVERHEAD)   # ONE round trip, regardless of batch size
    return [{"id": i} for i in item_ids]

item_ids = list(range(100))

start = time.perf_counter()
for item_id in item_ids:
    fetch_one(item_id)
t_unbatched = time.perf_counter() - start

start = time.perf_counter()
fetch_batched(item_ids)
t_batched = time.perf_counter() - start

print(f"unbatched (100 calls): {t_unbatched:.3f}s")
print(f"batched (1 call):      {t_batched:.3f}s")
print(f"batched is {t_unbatched / t_batched:.0f}x faster")

5

Each call to fetch_one pays the fixed round-trip cost individually — 100 items means 100x that cost.

9

fetch_batched pays the SAME fixed cost only ONCE, regardless of how many items are in the batch.

unbatched (100 calls): 0.175s
batched (1 call):      0.002s
batched is 83x faster

Why this works: The simulated round-trip overhead is paid 100 times in the unbatched version and exactly once in the batched version — this is the same fixed-cost-per-call shape a real database's N+1 query problem has, just made concrete with a stand-in delay instead of a real network call.

What we're doing: Measure the real cost of json.dumps at scale, showing serialization is a genuine, measurable expense, not free.

import json
import time

records = [{"id": i, "name": f"user_{i}", "active": True} for i in range(100_000)]

start = time.perf_counter()
serialized = json.dumps(records)
elapsed = time.perf_counter() - start

print(f"serialized {len(records)} records in {elapsed:.4f}s")
print(f"output size: {len(serialized) / 1024:.1f} KB")

4

100,000 small dicts is a realistic size for a real API response or batch export.

6

json.dumps is doing real work here — walking every record and converting Python types to their JSON text representation.

serialized 100000 records in 0.0619s
output size: 5154.1 KB

Why this works: json.dumps genuinely spends measurable time (tens of milliseconds here) converting 100,000 Python dicts into a 4+ MB JSON string — at high request volume, or with larger payloads, this cost compounds into a real, profileable line item, not a rounding error.

What we're doing: Profile a program with a deliberately misleading structure — an innocent-looking call that is actually the real cost — and show cProfile catching what intuition would likely miss.

import cProfile
import pstats
import time

def looks_complex_but_is_cheap():
    return sum(i * i for i in range(1000))

def looks_simple_but_is_expensive():
    time.sleep(0.1)   # stands in for a real network call
    return "config loaded"

def main():
    for _ in range(3):
        looks_complex_but_is_cheap()
    looks_simple_but_is_expensive()

cProfile.run("main()", "measure_first.prof")
stats = pstats.Stats("measure_first.prof")
stats.sort_stats("cumulative")
stats.print_stats("measure_first")   # filter to just this file's own functions

5

This function has a comprehension inside a generator — it LOOKS like the interesting, complex part of the program.

8

This function looks trivial — one line — but is actually the genuine cost, standing in for a real network call.

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.000    0.000    0.101    0.101 measure_first.py:12(main)
        1    0.000    0.000    0.100    0.100 measure_first.py:8(looks_simple_but_is_expensive)
        3    0.000    0.000    0.001    0.000 measure_first.py:5(looks_complex_but_is_cheap)
     3003    0.000    0.000    0.000    0.000 measure_first.py:6(<genexpr>)

Why this works: looks_simple_but_is_expensive shows cumtime 0.100 — nearly the entire program's runtime — while looks_complex_but_is_cheap, despite its nested generator expression running 3,003 times, shows cumtime only 0.001. The function with visually complex code barely registers; the visually trivial one dominates — exactly the mismatch between "looks complicated" and "actually costs time" that makes guessing unreliable and profiling necessary.