skip to content

Your platform offers no flattened generic storage; how do you decide whether the team maintains hand-duplicated point buffers per element kind?

level: principalimportance: should knowfreq 30%

answer

  1. one buffer type per element kind
  2. the algorithm now exists N times
  3. duplicate only the hot kinds
  4. generate rather than hand-copy
  5. write the exit condition down

basics

~20 s

Weigh a measured gap on a real hot path against owning the same algorithm N times forever. Duplicate only the element kinds that are actually hot, generate the copies from one source rather than typing them, and write down the condition for deleting them.

solid answer

~50 s

The duplication buys exactly one thing — flat storage on a platform that will not give it to you generically — and charges for it every week afterwards. Before committing, I want a measured gap on a path that matters, not the mechanism recited; a small, stable set of element kinds that are genuinely hot; and a container whose operation set has stopped moving, because every future change now lands N times and drifts when one copy is missed. If those hold, I keep the blast radius small: duplicate the storage for the two or three hot kinds rather than every kind, generate the copies from one source of truth so no copy is ever hand-edited, and run one shared test suite against all of them. I also record the exit condition — the platform gaining flat storage, or the hot path moving — so the copies do not outlive their reason.

go deeper

for a junior

Recall the trade in one line: hand-written per-element buffers get flat storage, and the price is the same code existing several times over.

for a middle

Explain why the recurring cost dominates the writing cost, and why generating the copies from one source removes the drift that hand-copying guarantees.

for a senior

Show how you would scope it: measure first, duplicate only the hot element kinds, keep the layout-independent algorithms in one place, and run one suite against every copy.

for a principal

Own the commitment. State what evidence justifies N copies, how the blast radius is contained, and what condition retires them — a decision without an exit condition becomes permanent by default.

## The decision on the table The platform's generic container has one shared body and therefore a reference-shaped slot, so every coordinate point in a buffer is a separate object. The only way to get a flat block on such a platform is to stop being generic: write a buffer type **per unboxed element kind**, each one storing its own element inline. The question is not whether that is faster — measurement settles that — but whether the team should own it. ## What the duplication buys - **Flat storage today**, without waiting on a platform capability. - **A footprint near the payload**, which matters most where element counts are large and long-lived. - **One memory touch per read** and real sequential locality on the hot scan. - **Full control** of the layout, including packing choices the generic container would never make. ## What it charges, forever 1. **The algorithm now exists N times.** Every fix, every new operation, every performance change is applied N times, and the copies drift the first time someone updates one and misses another. The cost is not writing the copies; it is every change after that. 2. **The API surface multiplies.** Callers, tests, documentation and tooling all see N types where they saw one. 3. **Genericity is gone at the boundary.** A routine that wants to work over any of the buffers has to go back through the shared, reference-shaped path — which re-wraps at that boundary and hands back the cost the duplication removed — or be duplicated itself. 4. **Onboarding cost.** Every new engineer has to learn why there are N of these and which one to reach for. ## How to pay less for it - **Generate, do not copy.** Emit the copies from one source of truth so that a fix is typed once and regenerates everywhere. Drift only exists where a copy can be hand-edited. - **Duplicate the hot kinds only.** Two or three element kinds usually carry the traffic; the rest can stay on the generic container with its wrappers, and nothing is lost. - **Duplicate storage, not the whole library.** Keep the algorithms that do not touch the layout in one place and let the duplicated types provide only the storage and element access. - **One test suite, N targets.** Run the same behavioural suite against every copy through a shared harness, so a copy that drifted fails immediately. - **Contain it.** One owning module with a narrow public surface, not a pattern the whole codebase is invited to imitate. ## Reading the signals | signal | lean | |---|---| | a measured gap on a buffer traversed every frame | duplicate — the cost is on the hot path | | millions of elements held for the whole run | duplicate — footprint and locality both scale with count | | two or three element kinds actually hot | duplicate those, leave the rest generic | | the container's operation set still changing weekly | wait — every change would land N times | | measurement shows the layout costs a few percent | keep the shared body; the maintenance outweighs it | | the platform is about to offer flat generic storage | wait — the copies would be born as debt | ## The part a lead actually owns Anyone can compare the two layouts. What a lead owns is the **commitment**: this team will carry N copies of one algorithm for as long as the reason holds, and someone must notice when it stops holding. So the decision is written down with its measurement, its scope (which element kinds, which module), and its **exit condition** — the platform capability that would let the copies be deleted, or the profile change that would make them pointless. Without that last part the copies quietly become permanent, and the argument that justified them is remembered by nobody who has to maintain them.

  • How do you keep hand-duplicated buffers from drifting apart?
    Generate them from one source of truth instead of copying by hand, and run one behavioural test suite against every copy through a shared harness. Drift happens when a fix is typed into a single copy; if no copy is ever hand-edited, the fix lands once and regenerates everywhere.
  • What is the exit condition for the duplication?
    The platform gaining flat storage for generic containers, or measurement showing the hot path has moved. Record it with the decision: otherwise the copies outlive their reason and become something every new engineer has to learn and nobody has authority to delete.
  • A routine needs to work over all the duplicated buffers. What does that cost?
    It either goes through the shared reference-shaped path, which re-wraps elements at that boundary and gives back the win, or it is duplicated too. That is why the duplication should stay narrow: the more code that wants to be generic over these buffers, the worse the trade gets.

saying these in an interview costs you the question

  • Duplicates every element kind rather than the two that are hot
  • Hand-edits one copy and assumes the others will follow
  • Counts the cost of writing the copies, not of changing them forever
  • Assumes duplicated buffers can still be used generically for free
  • Takes the decision with no condition for ever deleting the copies