A recalculation pass stopped running in parallel after one formula began recording each evaluation — why did unrelated formulas slow down?
answer
- the analysis reasons over a region
- one write, no proof of independence
- unknown resolves to unsafe
- how often it ran became visible
- blast radius is not proportional
basics
~20 sThe recording is a channel the analysis cannot see through, so independence can no longer be proved for the pass. Optimisers reason conservatively over a whole region, and one shared write pins the schedule for everything inside it.
solid answer
~50 sBecause the property the engine relies on belongs to the pass, not to the cell. Once one formula writes shared state, two things stop being true at once. Independence can no longer be established: the analysis must assume other formulas might observe that state, and where it cannot prove otherwise it takes the safe option and serialises. And the *number and order* of evaluations becomes observable, so the engine may no longer skip a redundant evaluation, evaluate something speculatively, or let two workers interleave freely. How far the damage spreads depends on how precisely the engine can scope the effect, not on how much of the code is impure — one cell is enough to pin a whole region. That asymmetry is the practical argument for keeping effects at the edge of a computation rather than sprinkled through it.
code
pseudocode · 6 linesfunction priceRow(row):
auditCount = auditCount + 1 # shared write: an observable effect
return row.qty * row.unitPrice
# the engine must now preserve how often, and in what order, priceRow runs,
# so the pass containing it loses reordering, reuse and parallel splittinggo deeper
Take away the headline: writing to something shared during a calculation is not a private detail of that calculation, because it changes what the surrounding system is permitted to do with it.
Explain conservative analysis. An optimiser applies a rewrite only when it can prove behaviour is preserved, so one statement it cannot reason about withdraws the proof for its whole region.
Diagnose it from symptoms: a step change tied to a deployment, time spread across everything rather than concentrated, and a region that recently gained a write outside its declared outputs.
Own the boundary. Decide where in the system effects are permitted to live, and treat that line as an architectural invariant, because scheduling freedom everywhere else depends on it holding.
## What the pass lost Nothing about the arithmetic changed. What changed is the set of transformations the engine is still allowed to apply, and that set was never a property of the individual formula — it was a property of the region the engine analyses. The recording turned a region it could reason about into one it cannot, and a sound optimiser that cannot prove a rearrangement is safe does not attempt it. This is why the symptom is so counter-intuitive in production: the slowdown appears in formulas nobody edited, and it is far larger than the cost of the write itself. ## Two guarantees, gone together 1. **Provable independence.** Previously the engine could show that any two formulas interacted only through declared cells. Now one formula reaches state outside that graph, so for any pair involving it — and, depending on how coarsely the effect is scoped, for pairs that merely might reach the same state — the engine can no longer prove the order does not matter. Conservative analysis resolves *unknown* as *unsafe*. 2. **Unobservable evaluation count.** A pure evaluation leaves no trace, so how often and in what order it happened was not part of the answer. Once each evaluation writes a record, both become part of the answer. Any transformation that changes them is now a behaviour change. ## Which transformations that actually costs | Transformation | What it needs | Status after the write | |---|---|---| | Reorder against a neighbour | No interaction outside declared cells | Lost — interaction can no longer be excluded | | Evaluate once, reuse the value | Skipping an evaluation loses nothing | Lost — skipping loses a record | | Evaluate speculatively | Discarding the result costs only work | Lost — a discarded evaluation still wrote | | Split the pass across workers | No shared writable state | Lost — the record is shared and written | Four distinct optimisations disappear on a single change, which is why the measured slowdown is disproportionate to the write. ## Why the damage is not local - **The analysis works over regions,** not statements. It answers *can this region be reordered or split?* and one unknown inside it answers that for the whole region. - **Precision costs analysis effort.** An engine that can prove the effect reaches nothing else may quarantine it; a simpler one widens the blast radius to whatever it can describe cheaply. - **Blast radius is not proportional to how much code is impure.** One cell in ten thousand is enough. This is the asymmetry people underestimate: purity is a property you lose wholesale and regain only by removing every exception. - **Optimisations compound.** Splitting across workers was worth having partly because each worker could also reorder and reuse within its chunk; losing the foundation loses everything stacked on it. ## Reading the symptom The production signature is a step change in pass duration that correlates with a deployment, not with load, and a profile in which no single line got more expensive — the time is spread across everything, because the work that used to overlap no longer does. The diagnostic question is not *what got slower?* but *what did we stop being allowed to do?*, and the answer is usually found by asking which formulas in the region now touch anything outside their declared inputs and outputs. ## The move that fixes it The recording does not have to be abandoned; it has to stop being an act performed during evaluation and become a value produced by it. Each formula returns its result together with whatever it would have recorded, and one step after the pass writes the collected records in whatever order you choose. The evaluation stays a function of its inputs, the pass stays freely schedulable, and the ordering question moves to a single place where it is explicit and cheap to reason about. ## How this is asked This is a diagnosis question, and the weak answer is always the local one: *the write is slow.* The interviewer is watching for whether you understand that an optimiser trades in proofs — it applies a transformation only when it can establish that the transformation preserves behaviour — and that one unprovable statement invalidates the proof for everything around it. A strong answer names the lost transformations specifically, explains why the blast radius is not proportional to the size of the change, and ends on the structural fix rather than on advice to write fewer logs.
- The formula only reads a shared counter rather than writing one. Is the pass still pinned?It depends on whether anything in the pass writes that counter. If something does, a read of it makes the result depend on when the formula ran, which is the same unprovable-independence problem. If the counter is set once before the pass and never touched during it, it behaves as an ordinary input and constrains nothing.
- How can the recording be kept without giving up the parallel pass?Make it a value rather than an act. Each formula returns its result together with what it would have recorded, and a single step after the pass writes the collected records. Evaluation stays schedulable, and the question of ordering the records moves to one explicit place instead of being scattered through the sheet.
saying these in an interview costs you the question
- Assumes only the formula that was changed loses its optimisations.
- Says the write is cheap, so it cannot explain a large slowdown.
- Claims an optimiser can simply ignore a write it considers unimportant.
- Thinks evaluating something exactly once is safe even when it is recorded.
- Confuses the cost of the write with the cost of the parallelism that was lost.