Middle · Design · Measure allocations without confusing live memory

How would you compare two implementations with repeatable allocation and latency evidence?

Think through your answer before opening the explanation.

Memory & GC

Reveal answer and reasoning

Choose two implementations with identical validated results and a fixed input distribution. Record warmup policy, iteration count, runtime, GC mode and concurrency. Measure allocation throughput, completed operations and latency over comparable windows. Check surviving memory after a comparable lifecycle boundary. Include an adversarial input that changes sizes or cache hit rates so the result is not an accidental best case.

For an interview, explain how very high allocation can coexist with a stable live set and why a flat allocation rate can still feed a leak. Discuss synchronous thread-local counters versus async process-wide evidence. A strong answer distinguishes the metric's unit, scope and time interval, notes observer overhead, and avoids reporting one microbenchmark as proof of production tail latency under contention or cluster load.

Change the portable value before boxing rather than afterward and predict the exact output. Then compare a typed value collection with an object collection while preserving equivalent business results. Use a separate measured program rather than adding counters around Console.WriteLine and treating formatting as free.

Extend the SDK experiment with a no-retention variant that performs the same number of payload operations but discards each result after consuming it. Keep the consumption observable and explain how that changes the live set while allocation can remain similar. Finish by writing four separate questions: how much was allocated, how much survived, how much was committed, and how much process memory was resident.

What a strong answer covers

  • Allocated bytes accumulate even when objects die quickly.
  • Per-thread allocation counters cannot span arbitrary async thread switches.
  • JIT warmup, measurement allocations and escape behavior can change results.

Common pitfall

Using a per-thread counter across arbitrary awaits, or calling cumulative allocation a live-heap measurement.

Follow-up questions

  1. What allocations belong outside the timed interval?
  2. How would a no-retention variant change live bytes without eliminating allocation?

Self-review

Choose what to revisit. These marks are your own assessment and are separate from lesson completion.

Primary references

Open lesson and code ↗

← All interview questions