Your reflect-based row mapper is the hot path of a nightly ten-million-row batch: keep it, generate mappers, or go generic?

## The decision, not the benchmark All three options work. The question is which obligations you want to own for the next few years, and who else pays them. Framing this as "reflection is slow, generate everything" is the answer that reads well and ages badly. ## Step one: establish the ceiling before spending anything Measure the current mapper against a hand-written mapper for one representative struct — time and allocations per row, on rows already in memory so the database is out of the picture. That number is the *most* any change can buy. If the mapper is fifteen percent of a batch that is otherwise waiting on the database, the whole discussion is over and the right answer is to leave it alone and say so. Half the value of being the person who owns this call is being willing to close it. ## Step two: take the contained win Caching a plan per `reflect.Type` removes the repeated discovery and changes nothing outside the package: no new build step, no generated files, no change to what callers write. Re-measure after it. Very often the remaining gap no longer justifies anything structural, and you have spent one review on it. ## Step three: price the alternatives honestly **Generated mappers (`go generate`).** The runtime win is real: static field assignment, no boxing, and — the underrated part — a struct field renamed makes the *build* fail rather than row one of tonight's batch. The costs are organisational and permanent: - The generator becomes a dependency the module must pin, or two engineers produce different output from the same source. - Generated files are either checked in (reviewable, diffable, but able to go stale) or produced during the build (never stale, but now every build and every editor needs the generator). Checking in is the common choice, and it only holds if CI runs the generator and fails on a non-empty diff. Without that gate, checked-in generated code is a lie waiting to be discovered. - Every contributor now has a step to remember, including the ones who have never heard of this batch. - Generated code shows up in reviews, coverage and diffs, and someone has to own the template when the schema conventions change. **Type parameters.** Free of build-system cost and checked at compile time, but they cannot walk a struct's fields, so they shrink the dynamic surface rather than removing it. They also change the API: `Load[T]()` reads differently from `Load(dst any)`, and if other teams already call the old one, that is a coordinated change, not a refactor. ## Step four: decide the scope, which is where most teams go wrong The decision is rarely all-or-nothing. Two or three model types carry the volume; the long tail is mapped a handful of times a day. Generating for the hot types and leaving the tail reflective gets almost the entire win for a fraction of the obligation — at the price of two mechanisms in one codebase, which needs a written rule for which to use, or it degenerates into whichever the last author preferred. ## Step five: name who can overrule you A code-generation step is a build-policy change, so the platform or build owner has a legitimate veto, and their objection is usually correct: they inherit the CI gate and the support load. If the mapper is a shared library, the teams importing it inherit the API shape and, if generation is not hermetic, the generator too. Bringing them the measurement rather than the conclusion is what makes this a decision rather than an announcement. ## What a good answer sounds like "Measure the ceiling; cache the plan and re-measure; generate only for the types that carry the volume, and only with a CI gate that fails on stale output; keep reflection for the tail; and if the first measurement says the batch is database-bound, do none of it." What a weak answer sounds like: "reflection is slow, so we generate everything" — with no number, no owner for the generator, and no gate keeping the generated code honest.