242: Performance: Rendering, Lists, Search, Memoization, and Virtualization

Learning outcomes

By the end of this lesson, you can:

explain and apply render cost in a realistic implementation;
explain and apply derived computation in a realistic implementation;
explain and apply debounce and throttle in a realistic implementation;
explain and apply stable identity in a realistic implementation;
explain and apply virtualization in a realistic implementation.

Prerequisites and retrieval

This lesson builds on the earlier 01–06 foundation and the lessons that come before it in this module. Before you start, bring to mind one concrete example from a previous project where one of these concerns showed up. You are not trying to memorize a collection of performance terms. You are practicing how to make a defensible choice in a timed machine-coding exercise while keeping the result readable, accessible, testable, and straightforward to extend under interview pressure.

Terminology

Render cost: Determine what triggers rerenders and how much work happens during each render.
Derived computation: Filtering or sorting thousands of records on every keystroke may call for memoization or deferred/debounced work. With only tens of records, that additional complexity may not be justified.
Debounce and throttle: Debouncing waits until activity has been quiet for a period before acting; throttling limits how often an action can run.
Stable identity: Keys must continue to identify the same logical items when the list is reordered or updated.
Virtualization: Render only the rows that are visible in a very large list, without giving up keyboard, focus, or accessibility expectations.
Measurement: Use browser profiling or simple timing data before claiming that an optimization helped.

Mental model

Treat Performance: Rendering, Lists, Search, Memoization, and Virtualization as a design problem. It has observable inputs and outputs, invariants that must remain true, and failure modes that you should be able to describe. In machine coding, performance work should address obvious scaling risks; it should not turn every callback into a memoization exercise. A strong implementation makes its assumptions visible, reduces uncertainty at the boundaries, and leaves evidence—tests, types, constraints, metrics, or diagrams—that supports the safety of the design.

A useful sequence for both interviews and production work is:

requirement -> constraints -> model -> implementation -> failure analysis -> verification

Do not leap from a requirement straight to a library call. First write down what must remain true. Then select the mechanism that enforces that invariant. For example, a large dataset may justify virtualization, but the dataset size alone does not tell you how focus, keyboard navigation, or item identity should work.

Deep dive

1. Render cost

When a component feels slow, start by identifying what causes it to rerender and how much work each render performs. Correct state ownership often removes more unnecessary work than blanket memoization. If state that changes frequently lives too high in the tree, unrelated children may rerender even though their visible output has not changed.

Decision rule: Use render-cost analysis deliberately when it makes the contract or invariant easier to prove. If an optimization merely reduces typing while hiding an assumption, prefer the more explicit design.

2. Derived computation

Filtering and sorting thousands of records on every keystroke can make input feel sluggish. Memoization, deferred work, or debounced work may be appropriate, depending on whether the calculation itself or the frequency of updates is the bottleneck. For tens of records, the simpler direct calculation is often easier to understand and may be fast enough; complexity is not automatically an optimization.

Decision rule: Use derived computation deliberately when it makes the contract or invariant easier to prove. If it merely reduces typing while hiding an assumption, prefer the more explicit design.

3. Debounce and throttle

Debounce waits for a quiet period before acting, which is useful when intermediate values do not need their own request or calculation. Throttle caps the frequency of action, which is useful when updates should continue but must not happen on every event. Choose between them based on the user experience and network semantics, and cancel stale work when the operation supports cancellation.

Decision rule: Use debounce and throttle deliberately when they make the contract or invariant easier to prove. If they only reduce typing while hiding an assumption, prefer the more explicit design.

4. Stable identity

Keys must identify logical items across reorder and update operations. An array index describes a position, not an item, so it can cause local state and DOM nodes to be reused for the wrong record when the order changes. Use an identity that belongs to the item and remains stable for its lifetime in the list.

Decision rule: Use stable identity deliberately when it makes the contract or invariant easier to prove. If it only reduces typing while hiding an assumption, prefer the more explicit design.

5. Virtualization

Virtualization renders only the visible rows of a very large list, reducing the amount of DOM and rendering work. The optimization is not free: keyboard navigation, focus retention, measurement, and accessibility semantics still need an explicit design. Do not virtualize a 50-item list merely to demonstrate that you can add a library; use it when the scale and observed behavior justify the trade-off.

Decision rule: Use virtualization deliberately when it makes the contract or invariant easier to prove. If it only reduces typing while hiding an assumption, prefer the more explicit design.

6. Measurement

Use browser profiling or simple timing to establish where the time goes before claiming an optimization. After the change, demonstrate that the expensive path is actually smaller or less frequent. A mechanism that sounds scalable is not evidence by itself, and a faster calculation is not useful if it breaks focus or produces stale results.

Decision rule: Use measurement deliberately when it makes the contract or invariant easier to prove. If it only reduces typing while hiding an assumption, prefer the more explicit design.

Worked example

Consider a timed machine-coding exercise that must stay readable, accessible, testable, and easy to extend while you are working under interview pressure. Start by stating the requirement in one sentence. Then list the input and output contracts and map each likely failure mode to the concept or layer that owns it. The key move is separation: parsing and validation belong at the boundary; domain rules belong in the domain or service layer; persistence rules belong in the database or repository; presentation rules belong in the client. Combining these concerns can make a happy-path demo look shorter, but it makes edge cases much harder to reason about.

export async function handleRequest(input: unknown) {
  const command = parseCommand(input);
  const result = await service.execute(command);
  return toHttpResponse(result);
}

The function illustrates a boundary rather than a complete application. Untrusted input is parsed before the service sees it, the service owns the operation, and the result is translated into the transport format at the end. Keep those responsibilities distinct when you add search state, derived rows, or a rendering optimization; a UI optimization should not silently become validation or persistence logic.

Walk through at least four cases: the normal path, an empty or missing value, a duplicate/retry/concurrent path where that situation is relevant, and a dependency failure. For each case, identify the layer that detects the problem and describe what the caller observes. That level of reasoning is expected in a senior code review or technical interview, and it is more valuable than simply naming a performance technique.

Production perspective

Production correctness is broader than “the code works on my machine.” Ask how the design behaves during deploys, retries, partial failure, stale clients, concurrent requests, malformed data, schema changes, and high-cardinality workloads. Prefer explicit contracts, bounded resource usage, structured errors, and measurable behavior. Optimize only after you can identify the bottleneck or risk with evidence.

When an external dependency is involved, define how timeouts and cancellation work. When persistence is involved, define the transaction and consistency expectations. When user-visible state is involved, define loading, empty, error, stale, and success states. When security is involved, assume that the client can be modified and that network input is untrusted. Performance improvements do not replace these guarantees.

Guided lab

Create a searchable list with 10k rows. Measure the naive rendering and filtering behavior first. Then add only the minimum optimization the evidence supports, such as deferred input, memoized derivation, or virtualization, and record the before-and-after behavior.

Complete the lab with this discipline:

Write the requirement and two non-requirements.
List the input, output, and error contracts before implementation.
Implement the smallest correct vertical slice.
Add at least one invalid-input test and one edge-case test.
Instrument or inspect the behavior instead of guessing.
Refactor one hidden assumption into an explicit type, constraint, function, or configuration.
Explain one alternative design and why you did not choose it.
Record a short “what would break at 10× scale?” note.

The point of the lab is not to collect optimizations. It is to connect an observed bottleneck to a narrowly scoped change and then verify that the change preserved behavior.

Edge cases and failure modes

Render cost: Test absence, malformed input, duplicates, ordering/concurrency where applicable, and behavior at the smallest and largest credible sizes.
Derived computation: Test absence, malformed input, duplicates, ordering/concurrency where applicable, and behavior at the smallest and largest credible sizes.
Debounce and throttle: Test absence, malformed input, duplicates, ordering/concurrency where applicable, and behavior at the smallest and largest credible sizes.
Stable identity: Test absence, malformed input, duplicates, ordering/concurrency where applicable, and behavior at the smallest and largest credible sizes.
Virtualization: Test absence, malformed input, duplicates, ordering/concurrency where applicable, and behavior at the smallest and largest credible sizes.

These cases are useful because performance code often changes timing or reuse without changing the apparent happy path. Test that the output remains correct, that stale work cannot overwrite newer work where applicable, and that the smallest input does not acquire unnecessary complexity merely because the largest input needs it.

Common mistakes and debugging

Solving the example instead of the requirement: a copied pattern can be syntactically correct but architecturally wrong.
Hiding uncertainty with assertions, broad exception handlers, permissive schemas, or “temporary” any values.
Testing only the happy path and therefore discovering contracts only after integration.
Optimizing before measuring, or selecting a scalable mechanism without a scale requirement.
Letting client-side behavior stand in for server-side authorization, validation, or persistence guarantees.

For debugging, reproduce the smallest failing case first. Inspect the actual value or execution plan, trace the boundary where the invariant first becomes false, and fix the layer that owns the problem instead of adding a downstream patch. In a rendering issue, that may mean inspecting state ownership and profiler output; in a stale search result, inspect request timing and cancellation; in a list bug, inspect item identity and reorder behavior.

Interview questions

What problem does Render cost solve, and what trade-off or failure mode would make you choose a different approach?
What problem does Derived computation solve, and what trade-off or failure mode would make you choose a different approach?
What problem does Debounce and throttle solve, and what trade-off or failure mode would make you choose a different approach?
What problem does Stable identity solve, and what trade-off or failure mode would make you choose a different approach?
What problem does Virtualization solve, and what trade-off or failure mode would make you choose a different approach?

Checkpoint

Without notes, explain Performance: Rendering, Lists, Search, Memoization, and Virtualization to another developer in five minutes. Include one invariant, one edge case, one production failure mode, and one alternative design. Then implement a small example without copying the lesson code.

Mastery checklist

I can define the core terms precisely.
I can choose a design from requirements instead of from habit.
I can implement and test the normal path and edge cases.
I can explain the runtime, storage, or complexity cost.
I can identify which layer owns validation, errors, and recovery.
I can compare at least two reasonable alternatives.
I can explain how the design changes at larger scale or stricter reliability.