Benchmarking State Management Libraries in Data-Heavy React Apps

Hello, I'm Elina. I'm a front-end developer at PhysicsX. I'll show you today a production application experiment where I swapped state management libraries and measured their performance.

The question is, does the library choice significantly affect performance, or are the differences small enough that we should prioritize other parameters? I choose one of our applications for experiments. Optimizer is our engineering tool for running and exploring optimization jobs. It connects to our internal compute and AI libraries, so we can define objectives, constraints, parameters, run experiments, and analyze the results all in one place.

Where does all this data for visualization come from? As input, we have a sample with metrics, parameters, and geometry. As output, we get a lot of candidates. At each step of an optimization job, we can have thousands of candidates, and there can be thousands of steps. We store all this data in a database and send it to the web via REST API to inspect in different ways. There is a lot of data, so I'm always working on visualizing it clearly in a faster way. In reality, it looks like this. Data-heavy UI, quiz tables, charts, live updates, and 3D. We built this up last year, and we used Recoil for state management. It was fast, simple, and allowed until this year. Unfortunately, Recoil were archived, so we have to move.

But how do we decide what to switch to? First idea, Jotai. Similar models, easy migrations from atoms and selectors to atoms and derived atoms. Minimal code changes. We also use Redux Toolkit in another app, so the team knows, and it has a strong ecosystem and predictable flow. Zustand is lightweight with direct updates and simple selectors. MobX gives reactive states and computed values with granular subscriptions. In short, we had zero realistic paths. So now here the state management libraries I will compare. Zustand, small global store with direct updates, Redux Toolkit, centralized store with action-reducer flow, Recoil, atom-based state with selector, Jotai, atom-based state with derived data, MobX reactive state that autosyncs with UI. All of them have different internals, different designs, and different costs when they're up and released. But the question is, does this difference actually matter in real app? I use same app, same pages, same components, same data sets, same UI interactions. I only swap state management integrations. No architecture rewrite. And because this app was originally written for Recoil, other libraries may encounter patterns that are not perfect for them.

That is reality in most real migrations. So instead of guessing complexities, I decided to measure real timings. For the first experiments, I disabled infinite scroll in our list of optimization and loaded exactly five batches. Each next batch contained larger optimization by increasing the amount of steps in this optimization. Same data for every library. Each library is tested more than 10 times. We will be measuring safe-to-state time, time to update the state with new data, and trend of time. Time for React components to render after start update.

And we will measure this on a scaling. How these times grow as payload size increase across batches. How we are measuring safe-to-state time? Right before writing to the store, we start a timer. We save the batch using set optimization, and then wait for micro-tasks with await promise resolve. After that, we stop and compute the save time. Report batch number, data size, library, and measure times to the server. How we are measuring render time? We wrap the table container with recoil profile, and on the render callback, we use commit time to compute render time. Then, send the render measurement for that batch to the server.

Let's look at the results. Here, I run the exact same test 10 times per library. Each run loads five batches with growing payloads. And I display three things, render time, safe-to-state time, and the total time. These numbers depend a lot on my code and how well I know each library. So, that big spike is likely on me, not as a stand. On the next slide, I drop it and focus on Jotai, MobX, Recoil, and RTK. First batch is always the slowest, because this is a moment when the state and UI transition from empty to real data. The store creates its initial structure, and the table builds its layout for the first time. Payloads increases, but performance barely changes. So, the bottom line isn't memory transfer. It's mostly UI and subscription work on the first update. Jotai keeps states small and per atom. We compute only what we read, which helps to win on save time.

But derived chains can add a bit more work on read compared to Redux and Recoil. And I'm actually expected to Recoil and Jotai to match closely, because both use atom style state. Instead, Recoil often sits near to Redux. Recoil builds a dependency graph of atoms and selectors and cache-derived values. The cache helps read but adds some overhead on save time, especially for the first time. RTK goes through reducers and often use Immer, which makes immutable updates easier, but adds work when on save. It might be the reason why it's slower than Jotai.

Redux also narrows subscription, so only the right components render, which can lend it new Recoil in practice. MobX is very fine-grained and reactive. Only the paths you observe render, but when many observables change, at once the save can cascade through computed values and reaction. My app is shaped around atom selectors and slice reducers that favor Recoil, Jotai, and RTK. MobX can shine with domain stores of observable objects. Here is paid a small structure tax. Of course, the result depends a lot on component structure and how I'm fetching data.

This is a benchmark of my app, not an epsilon ranking. Now, let's test user interactions. Here, I click a candidate in any plot. The same candidate should highlight across all other plots. And the side view opens with details of the candidate. The goal is simple. State update, propagate, every subscriber reflects the same selected candidate. So, click, all plots highlighted, side view opens. As soon as I click, I start a timer in OnClick before any rendering happens. We measure state propagation only. Not React render time, not plot painting time.

Those can take, actually, 8,000 milliseconds on large datasets. So, we keep them out. We dispatch the candidate and stop the timer only when all plot subscribers receive the same selected candidate and side view store is updated by candidate info. We repeat this many times and calculate an average per library. Here, the difference exists. But they're small. Everything is around 5, 4 milliseconds. And in this use case, the rendering time is much bigger. 8,000 milliseconds. So, here, switching libraries won't magically improve performance. The cost isn't in rendering. The cost is in rendering, not in the state.

Let's look at another experiment. Here, we open the inspector page with serial-linked plots that tracked the same optimization. As new batches arrive from the back end, each plot appends new points and stay in sync across the page. The moment a batch lands, we need to update all visible plots quickly. This use case, stress propagation. One incoming update has many plot subscribers. And we should show our optimization in progress in real life.

So, we open inspector page with multiple linked plots. We subscribe the page to live optimization batches. Receive batches for one or more optimization. Each batch is injected into the client store. Then, plots that depend on that series get the new slice. We avoid historical data and try to append rather than replace arrays. Append the new points and keep plots in sync. Start at the client handler when a batch is received. Stop when every target plot signals. It rendered the new points. Same run comparison.

All libraries focus on identical optimization and are measured for performance. The measurement includes storable dates. Results indicate the time taken after fetching a new batch and rendering new data on plots. While there is less data to save compared to the first experiment, there are more places to update and view data simultaneously. Rankings show Recoil, MobX, Jotai around two seconds, and Zustand, RTK around four seconds.

UI was initially designed around recoil atom state selectors, providing natural benefits. Recoil atom selectors and Jotai atoms graph avoid raw renders by updating only dependencies, while MobX observable graph triggers targeted reactions. RTK and Zustand may require more work on narrowing the gap with memoize selectors, subscribers, careful state slicing, and batch updates. Global store models rely on immutable updates and selectors, with many subscribers rendered without tight memoization.

For live high subscription charts, dependency graph stores perform best in the app. RTK and Zustand can improve with careful selector designs and batching. Despite differences, all libraries are fast enough for real users. The differences in propagation are in milliseconds, while heavy rendering work is in hundreds of thousands. Choose a library that aligns with your data structure, design state shape and subscription boundaries accordingly for optimal performance. Performance is not just about the state library; it's about how well your application fits into it. Thank you for listening.