Your client app ships under a hard download-size budget - how do you decide where per-argument body generation is worth it?

## Why there is no codebase-wide answer Per-argument body generation buys a direct, inlinable call with no run-time indirection, and pays in build time, artifact bytes and instruction footprint. Whether that trade is good depends on quantities that differ per routine: how large the generated body is, how many distinct arguments it is used with, how far the expansion propagates into composed generic routines, whether those bodies coincide and merge, and whether the path is hot enough that a per-call saving is observable at all. Those quantities are not properties of the codebase, so a rule stated at codebase level is guaranteed to be wrong somewhere - either paying bytes for cold code or giving up speed on the path that matters. Under a hard download budget the asymmetry sharpens. Bytes are paid by every user, on first load, whether or not the code runs. Speed is paid back only on paths that actually execute, often enough to matter. A blanket generate-everything policy therefore charges everyone for a benefit that a minority of the code delivers. ## What to measure before deciding 1. **Attribute the artifact.** Break shipped size down to instantiations, not to source files. The question you need answered is which generic routines, at which type arguments, own the bytes - and duplication is the ceiling on that, since some bodies will have merged. 2. **Find the hot paths on the real workload**, not on a benchmark that exercises one argument. A component benchmark cannot see instruction-cache contention with the rest of the application. 3. **Measure the candidate path both ways.** The per-call saving and the footprint cost are in different units, and only a measurement on the assembled application converts between them. 4. **Watch build time as its own series.** It is the cost the team pays daily, it is not reclaimed by any merging step, and it degrades quietly. ## The shape of a defensible policy | Input | What it pushes toward | |---|---| | Path is measurably hot | generating bodies for the dominant argument | | Routine is small, few distinct arguments | generating - duplication is cheap here | | Wide routine, many arguments, composed deeply | one shared body - the expansion is multiplicative | | Code is cold or rarely reached | one shared body, whatever its call cost | | Budget already close to the ceiling | shared body by default, generation by exception | A policy other teams can follow needs three parts and not more: a default (shared body), an exception process (generate where a measurement on the real workload shows the path is hot and the win survives), and an enforcement point (a size gate in the build that fails when the artifact crosses its ceiling, so a regression is caught by the build rather than by a user on a slow connection). ## Keeping the choice reversible The worst outcome is not picking wrongly; it is picking in a way that cannot be revisited. Keep the decision reversible: - Keep the strategy choice out of the calling code, so switching a routine does not ripple into its callers. - Resist letting type arguments proliferate at the top of a composed chain, since each one multiplies bodies through every level below. - Record why each exception was granted, with the measurement attached, so a later engineer can re-test the claim instead of inheriting it as folklore. - Re-run the attribution each release. New arguments arrive with new features, and the artifact drifts without anyone deciding anything. ## What to say out loud in the interview The honest conclusion is the one to state plainly: this is decided per hot path with measurements, not declared once for a codebase, and the decision has a shelf life. Two failure modes are worth naming as the things you are protecting against. The first is optimising for a benchmark loop instead of the shipped artifact, which produces a fast component inside an application nobody can download. The second is deferring size work to a later release, which never comes, because every release adds arguments and none removes them. A lead's real deliverable here is not a preference between two compilation strategies. It is the budget, the attribution that makes the budget actionable, the gate that enforces it, and a rule narrow enough that the engineers applying it do not have to re-derive the trade-off every time they write a generic routine.