## Engineering terms: performance

From Vibe Coding 101 (https://vibe-coding-101.brighteng.org/). When a request describes one of these problems, use the named technique, say its name, and run its check. Each term's page has the full entry and a prompt.

- **memoization**: Reuse a computed result while its inputs are unchanged. Use when: Profiling shows repeated expensive computation during rendering. Do: Measure the expensive operation first. Check both correctness after input changes and actual work avoided. Avoid: A cache with incomplete dependencies displays a stale result.
- **layout thrashing**: Alternating DOM reads and writes forces the browser to recalculate layout repeatedly. Use when: An interaction stalls while repeatedly measuring and resizing elements. Do: Measure the interaction, group compatible reads and writes, and recheck after content changes. Avoid: Caching geometry that becomes stale when the layout changes.
- **critical rendering path**: The critical rendering path is the work needed before the browser can render content. Use when: A page waits for unrelated resources before showing useful content. Do: Trace the initial load and remove or defer work that does not support the initial content. Avoid: Preloading everything and reducing the relative priority of important resources.
- **tail latency**: Tail latency describes the slow end of a response-time distribution. Use when: Average latency looks healthy while some users wait much longer. Do: Measure a representative distribution and trace the operations behind slow requests. Avoid: Reporting p99 from too few samples to support a useful estimate.
- **cold start**: A cold start includes initialization work before a new instance can serve its first operation. Use when: Initial requests are much slower than requests to an already-running instance. Do: Measure cold and warm paths separately and move only safe reusable initialization into the appropriate lifecycle. Avoid: Optimizing a warm benchmark and reporting it as cold-start improvement.
- **list virtualization**: Render a window of list items instead of every item at once. Use when: A long list spends too much time or memory rendering off-screen rows. Do: Measure the list, preserve stable identity, and test scrolling, focus, and variable content. Avoid: Recycling a row without resetting state that belongs to a different item.
- **memory leak**: A memory leak retains memory beyond its useful lifetime. Use when: Memory grows after repeatedly opening and closing a feature. Do: Reproduce the lifecycle repeatedly and compare retained objects or allocations. Avoid: Declaring a leak fixed because garbage collection temporarily lowered one sample.
- **lock contention**: Lock contention occurs when operations wait to acquire the same synchronization boundary. Use when: Many independent operations queue behind one protected section. Do: Measure hold and wait time, then reduce unnecessary shared work without losing the invariant. Avoid: Creating a per-key lock map that grows forever.
- **game loop**: A game loop coordinates repeated input, simulation, and rendering. Use when: Gameplay updates are spread across unrelated timers. Do: Choose the engine’s supported update phases and keep state changes separate from drawing. Avoid: Adding another timer that mutates the same simulation state outside its update phase.
- **delta time**: Delta time is elapsed time between updates. Use when: Movement speed changes when frame rate changes. Do: Express rates consistently and choose a bounded fixed or variable timestep strategy. Avoid: Allowing one unusually long timestep to cross obstacles or destabilize the simulation.
- **object pool**: An object pool reuses instances instead of creating a new one for each use. Use when: Profiling shows frequent allocations or expensive resource creation causing pauses. Do: Measure the allocation cost, define exhaustion behavior, and reset all reusable state. Avoid: Adding pooling where normal allocation was inexpensive and the extra retained memory is larger.
- **frame budget**: A frame budget allocates the time available for responsive rendering at a target cadence. Use when: An interaction drops frames during updates or rendering. Do: Trace representative frames and identify the work exceeding the chosen target. Avoid: Moving work off the main thread but waiting synchronously for its result each frame.