Performance Notes

What comprehensions, generators, map/filter and vectorized libraries actually cost, how to measure it, and when each wins. Readability decides most choices; this file is for the cases where speed or memory matters.

#Contents

• Measured timings
• Why comprehensions beat append loops
• map and filter
• Generators: memory, not speed
• join, sorted and other materialising consumers
• Vectorization with numpy, pandas and torch
• Hoisting work out of the loop
• Measuring correctly
• Memory measurement
• Decision summary

#Measured timings

CPython 3.14, 100,000 items, python -m timeit best of 5. Absolute numbers vary by machine and version; the ratios are what matter.

numpy 2.x on the same machine, 100,000 floats:

Takeaways:

1. A comprehension is modestly faster than an append loop: about 5 to 10 percent on 3.11+ (the adaptive interpreter specialises list.append); the gap is larger on 3.9/3.10. Re-measure on your version before quoting numbers.
2. map/filter with a lambda are the slowest option. With a builtin (str, len, str.strip, operator.itemgetter) map is as fast as or faster than a comprehension.
3. A generator is slower per item than a list for cheap elements. Use it for memory and short-circuiting, not speed.
4. A builtin that does the whole job (sum(xs), max(xs), set(xs)) beats any comprehension.
5. Iterating a numpy array element by element in Python is worse than iterating a list: each element is boxed into a numpy scalar.

#Why comprehensions beat append loops

The loop pays, per item, for loading out, looking up .append, and calling it. A list comprehension uses a dedicated LIST_APPEND bytecode. Since 3.12 (PEP 709) list, dict and set comprehensions are inlined into the enclosing function, so there is no extra function object or frame either.

import dis
dis.dis("[x * 2 for x in xs]")      # shows LIST_APPEND, no CALL to append

Micro-optimising the loop by caching the method (append = out.append) closes most of the gap but costs readability. Prefer the comprehension.

#map and filter

map and filter return lazy iterators in Python 3; wrap with list() when you need a list.

#Generators: memory, not speed

A list of 100,000 ints costs about 800 KB for the pointers alone (sys.getsizeof([0] * 100_000) is 800,056 bytes) plus the objects. A generator object is about 200 bytes regardless of length.

import sys
sys.getsizeof([0] * 100_000)                     # 800056
sys.getsizeof(x for x in range(100_000))         # ~200

When this matters in AI code:

• summing token counts over a corpus of millions of documents;
• any/all over expensive checks (model calls) where short-circuit saves money;
• streaming JSONL training data that does not fit in RAM;
• reading embeddings shard by shard into a vector store.

When it does not: small lists, data you will index or iterate twice, and anything passed to a consumer that materialises it anyway.

#join, sorted and other materialising consumers

str.join needs the total length before copying, so it converts any iterable to a list first. Passing a list comprehension avoids the generator overhead and is slightly faster. Same for sorted, tuple, np.array, torch.tensor, pd.DataFrame.

context = "\n\n".join([chunk.text for chunk in top_chunks])   # fine, marginally faster
context = "\n\n".join(chunk.text for chunk in top_chunks)     # also fine

#Vectorization with numpy, pandas and torch

When the data is numeric and already in an array, do not loop in Python at all.

Top-k retrieval over embeddings:

import numpy as np

def top_k(query: np.ndarray, doc_matrix: np.ndarray, k: int = 5) -> np.ndarray:
    """Indices of the k most similar rows (cosine), best first."""
    q = query / np.linalg.norm(query)
    d = doc_matrix / np.linalg.norm(doc_matrix, axis=1, keepdims=True)
    sims = d @ q
    idx = np.argpartition(-sims, kth=min(k, len(sims) - 1))[:k]
    return idx[np.argsort(-sims[idx])]

Comprehensions still have a place around vectorized code: building the input arrays from Python objects, and mapping indices back to objects.

doc_matrix = np.array([c.embedding for c in chunks], dtype=np.float32)
best = [chunks[i] for i in top_k(q_vec, doc_matrix, k=5)]

pandas: df.apply(f, axis=1) is a Python loop in disguise; a list comprehension over zip(df["a"], df["b"]) is often faster than apply, and a vectorized column expression is faster than both.

torch: avoid [t.item() for t in tensor] (one device sync per element); use tensor.tolist() once.

#Hoisting work out of the loop

The biggest wins are rarely loop-vs-comprehension; they are work done per item that could be done once.

# slow: regex compiled per item (cached, but still a lookup), set rebuilt per item
cleaned = [re.sub(r"\s+", " ", t) for t in texts if t.split()[0] not in set(STOPWORDS)]

# fast
WS = re.compile(r"\s+")
stop = frozenset(STOPWORDS)
cleaned = [WS.sub(" ", t) for t in texts if t.split()[0] not in stop]

#Measuring correctly

python -m timeit -s "xs = list(range(100_000))" "[x * 2 for x in xs]"
python -m timeit -s "from mymod import load; data = load()" "process(data)"

import timeit

setup = "texts = ['hello world'] * 10_000"
print(min(timeit.repeat("[t.upper() for t in texts]", setup, number=100, repeat=5)))
print(min(timeit.repeat("list(map(str.upper, texts))", setup, number=100, repeat=5)))

Rules: measure on realistic sizes, take the minimum of repeats, compare in the same Python version, and profile the whole program (python -m cProfile -s cumtime app.py or py-spy) before micro-optimising a comprehension that is not the bottleneck. In LLM apps the network call usually dominates by 1000x.

#Memory measurement

import tracemalloc

tracemalloc.start()
texts = [str(i) * 10 for i in range(100_000)]
current, peak = tracemalloc.get_traced_memory()
print(f"peak {peak / 1024:.0f} KiB")      # about 9.5 MiB on 64-bit CPython
tracemalloc.stop()

Compare peak memory of the list version and the generator version of a pipeline stage; for streaming code the generator version's peak should not grow with input size.

#Decision summary