The cheapest performance win is the work you never do

The claim

When an application is slow, the instinct is to make the slow work faster — optimise the query, add the cache, upgrade the hardware. The larger and cheaper win is usually elsewhere: not doing the work at all. A surprising fraction of what applications compute on every request is work whose result is never used, is recomputed identically thousands of times, or answers a question nobody asked. Eliminating that work costs nothing to run and never breaks, because the fastest code and the code least likely to fail is the code that does not execute.

The work that is computed and thrown away

The first category is work whose result is discarded. An endpoint loads a customer's full order history to display their name. A list page computes a total for every row when only the current page is shown. A report calculates figures for all regions when the user asked for one. In each case the work runs, consumes time and database load, and its output is mostly discarded — and because it produces a correct answer, nothing flags it as waste. It is invisible precisely because it works; it is just doing far more than the request required.

The fix is to compute only what the response actually uses. Fetch the name, not the order history. Total the visible page, not the whole table. Query the region asked for, not all of them. This is not optimisation in the usual sense — you are not making anything faster — you are removing work that never needed to happen, which is both cheaper and safer than speeding it up.

The work that is repeated identically

The second category is the same computation performed over and over with the same inputs and the same result. A configuration value parsed on every request instead of once at startup. A permission set recomputed for every item in a loop when it is identical for all of them. A currency conversion rate fetched per line item when every line shares it. None of these is expensive individually, which is why they survive — but multiplied by every request and every iteration, repeated identical work becomes a large fraction of total load, doing nothing new each time.

// before: the same lookup, once per item in the loop
for (const item of items) {
  const rate = fetchRate(item.currency);   // identical every iteration
  ...
}
// after: compute the distinct values once, reuse them
const rates = fetchRatesFor(distinctCurrencies(items));
for (const item of items) { const rate = rates[item.currency]; ... }

Hoisting the repeated work out of the loop, or computing it once and reusing it, removes it without changing what the code produces. The result is identical; the work is a fraction of what it was.

The work that answers an unasked question

The third category is the most insidious: features and computations built for requirements that turned out not to exist. An endpoint that returns thirty fields when the client uses three. A nightly job that generates a report nobody reads. A cache warmed for data that is rarely requested. This work is not wrong — it does what it was built to do — but it serves no actual need, and it accumulates because removing things feels riskier than leaving them, so systems grow a sediment of computation that made sense once and serves nothing now.

Finding it requires asking, of the expensive things your system does, who actually consumes the output. The report with no readers, the fields no client requests, the precomputed data nobody queries — each can be removed, and the way to remove it safely is to stop producing it and watch for anyone who notices. Silence means it was never needed.

How to find the work worth not doing

The measurement that reveals unnecessary work is different from ordinary profiling. Ordinary profiling tells you what is slow; here you also want to know what is frequent and whether its output is used. Two questions cut through most of it:

• For the most frequent operations, is all of the computed output actually used by the response? Log what an endpoint computes versus what it returns, and the gap is candidate waste.
• For the most expensive operations, does anyone consume the result? Trace the output to a real reader; if you cannot find one, you have found work to stop doing.

This is a different lens from "make the slow thing fast", and it frequently finds larger wins, because removing an operation entirely beats any percentage improvement to it — a query optimised to run twice as fast still runs; a query removed runs zero times.

The discipline going forward

The habit that prevents unnecessary work from accumulating is to question the need before building the thing, and to remove rather than optimise when work turns out to be unused. Before adding a computation, ask what consumes its result and whether the request in front of you actually requires it. Before optimising a slow operation, ask whether it needs to happen at all, or as often, or over as much data. The most reliable performance improvement is not a faster version of the work — it is the discovery that the work was never necessary, removed entirely, costing nothing to run and never appearing in an incident because code that does not execute cannot fail.