Memoization
debt(d7/e5/b3/t5)
Closest to 'only careful code review or runtime testing' (d7). The detection_hints note automated=no and tools are blackfire/xdebug — profilers that require deliberate instrumentation runs to spot repeated expensive calls. Misuse (memoizing side-effectful functions, wrong cache keys, unbounded growth) produces no compiler or linter warnings and won't surface until runtime profiling or user-visible bugs appear. Slightly better than d9 because profiling tools can expose the pattern if someone looks.
Closest to 'touches multiple files / significant refactor in one component' (e5). The quick_fix describes a static-variable cache keyed by arguments — seemingly a small change — but common_mistakes reveal that fixing a badly memoized function (wrong cache key, side effects bypassed, unbounded growth, cross-request stale state) often requires rethinking which functions are pure, auditing all call sites for side effects, and potentially introducing cache-eviction strategies. This goes beyond a one-line patch but stays within component scope, landing at e5.
Closest to 'localised tax' (b3). Memoization is typically applied per-function and its scope is contained within that function or class. It applies across web/cli/queue contexts but its structural weight is local — other parts of the codebase don't need to know about it. The risk of unbounded caches or cross-request static state adds a small ongoing tax, but it doesn't reshape the whole system.
Closest to 'notable trap (a documented gotcha most devs eventually learn)' (t5). The canonical misconception is treating memoization as equivalent to general caching — same concept, different scope and lifetime. Additionally, the common_mistakes list concrete, non-obvious pitfalls: memoizing functions with side effects silently skips those effects on repeat calls, and cross-request static properties without TTL cause stale data bugs. These are well-documented but regularly tripped over, placing this squarely at t5.
Also Known As
TL;DR
Explanation
Memoization is an optimisation for pure (or effectively pure) functions where the same inputs always produce the same output. The first call computes the result and stores it in a lookup table; subsequent calls with the same arguments return the cached result instantly. In PHP, this is commonly implemented with a local static array or instance property. It is most valuable for recursive computations (Fibonacci, tree traversals), repeated regex compilations, or expensive lookups (translations, configuration values) called multiple times per request.
Common Misconception
Why It Matters
Common Mistakes
- Memoizing functions with side effects — the cached result bypasses the side effect on repeat calls.
- Not including all deterministic inputs in the cache key — different inputs produce the same key, returning wrong results.
- Unbounded memoization caches — memory grows indefinitely for functions called with many unique inputs.
- Memoizing across requests via static properties without TTL — stale results persist for the process lifetime.
Code Examples
function expensiveCalc(int $n): int {
return // ... heavy computation each call
}function expensiveCalc(int $n): int {
static $cache = [];
return $cache[$n] ??= /* heavy computation */;
}