A Go agent binary for edge devices grew several megabytes in one release — how do you find why?

## Make the measurement trustworthy before you interpret it A size regression is one of the few production problems you can reproduce exactly, so do that first. Build both revisions: - on the same machine, with the same toolchain version — a toolchain upgrade alone moves size in both directions; - for the same target operating system and architecture; - with identical build flags and tags. `go version -m ./agent` prints the toolchain and the build settings recorded in each binary, which is the fastest way to catch an accidental difference in target or flags. If the two builds differ in anything but source, you are comparing noise. ## Look at symbols, not at the total `go tool nm -size -sort size ./agent | head -50` lists the largest symbols in a binary. Do it for both and diff the lists. Two shapes of answer come out: - **One or a few large new symbols.** Someone embedded an asset, generated a very large table, or vendored a big new component. This is the easy case and the total tells you almost everything. - **A broad new population of small symbols.** Hundreds or thousands of entries that did not exist before, clustered around type metadata, name strings and method tables. This is the interesting case and it means something changed what the linker is *allowed* to remove. The second shape is the signature of defeated dead-code elimination. The linker normally keeps a method only when it is called directly or when its type is boxed into an interface whose method name and signature match. Once a reachable code path looks methods up by a name computed at run time, the linker can no longer enumerate the possibilities and falls back to retention — and the retained methods drag their callees in behind them. ## Find the cause, not just the symptom With a candidate in hand, work backwards to what made it reachable: - Read the release's diff for anything that resolves a type or method **by string**: a registry keyed by type name, a plugin table, a decoder that maps a message kind to a handler by looking the name up. - Remember it can arrive indirectly. A package added for an unrelated reason may format arbitrary values or serialise unknown shapes, and reflection comes with it. - Check the module graph too: a dependency upgrade can introduce name-based dispatch inside code you did not write. ## Prove it The honest confirmation is a third build. Take the current revision, replace the suspected mechanism with a statically wired equivalent — an explicit map from a string key to a function value, populated by each type's own package at initialisation — and measure again. If the megabytes come back off, you have your cause and, incidentally, your fix. If they do not, your hypothesis was wrong and you have lost half an hour rather than a week. ## Then decide what to do about it Diagnosis and remedy are separate. Options, roughly in order of preference for a constrained target: - **Remove the need for name-based lookup** by generating or hand-writing the registration table. Static wiring is also compiler-checked, which the string version is not. - **Confine it.** If one subsystem genuinely needs dynamic dispatch, keep it behind a boundary and out of the artifact shipped to the constrained target, rather than letting it be reachable from every build. - **Accept it, with a number.** Sometimes the feature is worth the megabytes. Say so explicitly, record the new baseline, and make the artifact size a checked build output so the next regression is caught the day it lands rather than at the next device rollout. ## Keep the regression from recurring A size budget enforced in the build is worth more than any amount of after-the-fact archaeology: record the artifact size on every build, and fail when it crosses an agreed ceiling. The check costs nothing and turns a slow, deferred discovery into an immediate one, which matters most on targets where the artifact must fit a partition or be pushed over a slow link. ## What interviewers are checking That you control the variables before drawing conclusions; that you know a concrete tool for looking inside an artifact instead of reasoning from intuition; that you can recognise the difference between one big thing and a broad class of newly retained metadata; and that you confirm a hypothesis with a measurement rather than a plausible story.