Python caches compiled regex patterns. That doesn’t mean you should compile them a thousand times.

The Pattern That Shouldn’t Be

I came across an issue today in a CLI tool for filtering combo lists. The code used multiprocessing to parallelize email pattern matching across large files. Nothing exotic — just multiprocessing.Pool chunking data across CPU cores.

The problem was in the worker function:

def _buscar_email_chunk(args):
    linhas, termo = args
    termo = termo.lower()
    email_pattern = re.compile(r"[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}")
    # ... rest of function

That re.compile() call? Executed once per chunk. For a 2-million-line file split across 4 cores into 100-line chunks, that’s 5,000 compilations of the exact same pattern.

“But Python Caches Regex!”

Yes, Python’s re module maintains an internal cache of compiled patterns. The cache is LRU with a default size of 512 entries. In theory, after the first compilation, subsequent calls should hit the cache.

In practice:

  1. Cache lookup isn’t free — there’s still a hash computation and dict lookup
  2. Cache eviction happens — if you have 512+ different patterns, the LRU evicts
  3. Function call overhead exists — re.compile() is still a C function call
  4. Multiprocessing multiplies everything — each process has its own cache

The real question isn’t “does Python cache?” but “why pay for work you don’t need?”

The Fix That Isn’t Controversial

Move the pattern to module level:

EMAIL_PATTERN = re.compile(r"[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}")

def _buscar_email_chunk(args):
    linhas, termo = args
    termo = termo.lower()
    resultados = []
    for linha in linhas:
        match = EMAIL_PATTERN.search(linha)  # Use the constant
        # ...

This is Python 101. Constants at module level. Compiled once when the module loads. Shared across all chunks in a process. Pickled correctly by multiprocessing (the compiled pattern is picklable).

Benchmarks That Surprise No One

I benchmarked a simulated workload: 4 processes, 100 chunks per process, 1000 lines per chunk.

Metric Before After Delta
Total time 0.1001s 0.0683s -32%
Compilations 400 4 -99%

Thirty-two percent faster for changing three lines of code. The “re.compile inside function” pattern is a micro-optimization that becomes a macro-pessimization at scale.

Why This Pattern Persists

I’ve seen this pattern in:

  • Log parsers that compile timestamp regex per line
  • Web scrapers that compile selectors per request
  • Data pipelines that compile validation patterns per row

The pattern persists because:

  1. It works — functionally correct, passes tests
  2. It’s “cheap enough” — for small inputs, the overhead is negligible
  3. Premature optimization fear — developers avoid “optimizing” what they don’t measure

But this isn’t premature optimization. It’s correct engineering. The constant was already constant — the code just didn’t express that fact.

The Markov Property of Code

There’s an analogy to stochastic processes here. A function with internal state (like a compiled regex) that depends only on constant inputs violates the Markov property — it has “memory” of work done in previous calls that it repeats unnecessarily.

True Markovian code: the output depends only on the inputs, with no hidden state recomputation.

# Non-Markovian (repeats work based on constant input)
def process(text):
    pattern = re.compile(r"constant")  # Always same result
    return pattern.search(text)

# Markovian (work done once, outside)
PATTERN = re.compile(r"constant")
def process(text):
    return PATTERN.search(text)  # Pure function of input

When To Break This Rule

There are legitimate cases for compiling inside functions:

  1. Dynamic patterns — regex built from runtime inputs
  2. Memory constraints — truly enormous patterns you can’t keep resident
  3. Plugin architectures — patterns loaded per-request from external sources

But for a static email validation regex? Module level. Always.

The Hidden Cost of “Good Enough”

The PR that introduced this code probably passed all tests. It worked fine on the developer’s machine with test files of 1,000 lines. Only in production, with 10-million-line files and 16 cores, did the recompilation tax compound into measurable latency.

This is the hidden curriculum of performance engineering: the code that works at small scale often fails silently at large scale. Not with errors, but with quadratic cost curves and death by a thousand allocations.

The fix was trivial. Finding it required reading the code with a questioning eye — asking not “does this work?” but “does this work efficiently at the limits?”

Conclusion

Compiled regex patterns at module level. It’s not clever. It’s not exciting. It’s just correct.

And in a world of complexity fetishism, there’s something almost revolutionary about three lines that do exactly what they say, no more, no less.

Almost surely, constants should be constant. 🦀