Skip to content
tezvyn:

When can overusing useMemo hurt performance and what are the trade-offs?

Source: react.devMediumHow cards are made

When can overusing useMemo hurt performance and what are the trade-offs?
Summary

Awareness that useMemo has memory and comparison overhead.

Key points

Memoizing cheap work wastes cycles, increases memory use, and burdens dependency tracking.

Watch out for

Claiming useMemo is free or automatically blocks child re-renders.

What's really being asked

This question probes whether you understand that useMemo is not a zero-cost abstraction. Every call stores a cached value and an array of dependencies, then runs an Object.is comparison on every render before deciding whether to recompute. At senior level, interviewers want to see you treat memoization as a deliberate trade-off rather than a default habit, and that you know the difference between value memoization and render prevention.

The full answer

First, the runtime overhead. React must allocate an array, store the previous result, and iterate dependencies for comparison on each render. For cheap calculations like string concatenation or simple arithmetic, this comparison cost can exceed the cost of recomputing. Second, memory overhead. Cached values and their dependency arrays live for the lifetime of the component, which matters in long-lived lists or data-heavy dashboards. Third, complexity cost. Dependency arrays add maintenance burden and stale-closure risk; incorrect deps silently break caching or cause bugs. Fourth, the distinction between useMemo and React.memo. useMemo preserves a value reference, but a child component only skips rendering if it is wrapped in React.memo and receives that stable reference as a prop. Without React.memo, the stable reference alone does nothing to prevent child renders.

The mistakes people make

Saying useMemo is free or that it automatically prevents re-renders of children. Using useMemo on primitives like numbers or booleans where referential equality does not help. Wrapping every object or callback in useMemo without profiling first. Claiming that useMemo guarantees the calculation runs only once per dependency change, ignoring Strict Mode double-invocation during development.

What usually comes next

How would you profile whether useMemo is actually helping? When is it better to lift state or split components instead of adding useMemo? How does React Compiler change the manual useMemo trade-off? What is the difference between useMemo and useCallback in terms of what they cache?

A concrete example

Imagine a table with one thousand rows where each cell computes a formatted currency string via useMemo. The formatting is a single Intl.NumberFormat call that takes less than 0.05 milliseconds. The hook adds an array allocation and dependency checks for every cell on every render. In aggregate, that overhead exceeds the formatting cost, and the component uses several megabytes to retain cached strings that are rarely reused because filters change frequently. The better fix is either computing inline or virtualizing the table, not blanket memoization.

Interview question

A long-lived list component wraps a cheap per-item string format in useMemo. What net performance impact is most likely?

  • a.Child components automatically skip re-renders because the memoized strings have stable references.
  • b.The aggregate cost of dependency comparisons and array allocations exceeds the cost of recomputing the format inline.Correct
  • c.Memory overhead is minimal because React garbage-collects cached values immediately after each render.
  • d.The calculation is guaranteed to run exactly once per dependency change, even under React StrictMode.
Why?

For cheap computations, the per-render cost of dependency checks and array allocations across many items typically exceeds recomputation, and cached values persist for the component's lifetime. Option A is tempting but wrong because useMemo alone does not prevent child re-renders unless the child is wrapped in React.memo.

Just read this? Test yourself on what you have been reading.

Read the original → react.dev

You just looked this up. Could you explain it out loud?

That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.

The iPhone app is on the way

We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.

Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.

Get it on Google PlayiPhone app coming soon

We are hiring for this. Open roles that interview on react — each one lists the topics its interview covers.

See open roles