State Wars: Evaluación Comparativa de Estrategias de Gestión de Estado en Aplicaciones React Pesadas en Datos

Hola, soy Lina. Soy desarrolladora front-end en Physics X. Hoy les mostraré un experimento de aplicación de producción donde intercambié bibliotecas de gestión de estado y medí su rendimiento.

La pregunta es, ¿la elección de la biblioteca afecta significativamente el rendimiento, o las diferencias son lo suficientemente pequeñas como para que debamos priorizar otros parámetros? Elijo una de nuestras aplicaciones para experimentos. Optimizer es nuestra herramienta de ingeniería para ejecutar y explorar trabajos de optimización. Se conecta a nuestras bibliotecas internas de computación e IA, por lo que podemos definir objetivos, restricciones, parámetros, ejecutar experimentos y analizar los resultados todo en un solo lugar.

¿De dónde provienen todos estos datos para la visualización? Como entrada, tenemos una muestra con métricas, parámetros y geometría. Como salida, obtenemos muchos candidatos. En cada paso de un trabajo de optimización, podemos tener miles de candidatos, y puede haber miles de pasos. Almacenamos todos estos datos en una base de datos y los enviamos a la web a través de REST API para inspeccionarlos de diferentes maneras. Hay muchos datos, así que siempre estoy trabajando en visualizarlos claramente de una manera más rápida. En realidad, se ve así. UI pesada en datos, tablas de cuestionarios, gráficos, actualizaciones en vivo y 3D. Construimos esto el año pasado, y usamos Recoil para la gestión de estado. Era rápido, simple y permitía hasta este año. Desafortunadamente, Recoil fue archivado, así que tenemos que movernos.

Pero, ¿cómo decidimos a qué cambiar? Primera idea, JotAi. Modelos similares, migraciones fáciles de átomos y selectores a átomos y átomos derivados. Cambios mínimos de código. También usamos Redux toolkit en otra aplicación, así que el equipo lo conoce, y tiene un ecosistema fuerte y flujo predecible. Dustant es liviano con actualizaciones directas y selectores simples. Mubex ofrece estados reactivos y valores calculados con suscripciones granulares. En resumen, no teníamos caminos realistas. Así que ahora aquí las bibliotecas de gestión de estado que compararé. Dustant, pequeña tienda global con actualizaciones directas, Redux toolkit, tienda centralizada con flujo de acción-reductor, Recoil, estado basado en átomos con selector, JotAm, estado basado en átomos con datos derivados, Mubex estado reactivo que se sincroniza automáticamente con la UI. Todos ellos tienen diferentes internos, diferentes diseños y diferentes costos cuando están en funcionamiento y liberados. Pero la pregunta es, ¿esta diferencia realmente importa en una aplicación real? Uso la misma aplicación, mismas páginas, mismos componentes, mismos conjuntos de datos, mismas interacciones de UI. Solo intercambio integraciones de gestión de estado. Sin reescritura de arquitectura. Y debido a que esta aplicación fue originalmente escrita para Recoil, otras bibliotecas pueden encontrar patrones que no son perfectos para ellas.

Esa es la realidad en la mayoría de las migraciones reales. Así que en lugar de adivinar complejidades, decidí medir tiempos reales. Para los primeros experimentos, desactivé el desplazamiento infinito en nuestra lista de optimización y cargué exactamente cinco lotes. Cada siguiente lote contenía una optimización más grande al aumentar la cantidad de pasos en esta optimización. Mismos datos para cada biblioteca. Cada biblioteca se prueba más de 10 veces. Mediremos el tiempo seguro para el estado, el tiempo para actualizar el estado con nuevos datos, y la tendencia del tiempo. Tiempo para que los componentes de React se rendericen después de comenzar la actualización.

Y mediremos esto en una escala. Cómo crecen estos tiempos a medida que aumenta el tamaño de la carga útil a través de los lotes. ¿Cómo estamos midiendo el tiempo seguro para el estado? Justo antes de escribir en la tienda, comenzamos un temporizador. Guardamos el lote usando set optimization, y luego esperamos micro-tareas con await promise resolve. Después de eso, detenemos y calculamos el tiempo de guardado. Informamos el número de lote, tamaño de datos, biblioteca, y medimos los tiempos al servidor. ¿Cómo estamos midiendo el tiempo de renderizado? Envolvemos el contenedor de la tabla con el perfil de recoil, y en el callback de renderizado, usamos el tiempo de commit para calcular el tiempo de renderizado. Luego, enviamos la medición de renderizado para ese lote al servidor.

Veamos los resultados. Aquí, ejecuto exactamente la misma prueba 10 veces por biblioteca. Cada ejecución carga cinco lotes con cargas útiles crecientes. Y muestro tres cosas, tiempo de renderizado, tiempo seguro para el estado, y el tiempo total. Estos números dependen mucho de mi código y de qué tan bien conozco cada biblioteca. Así que, ese gran pico es probablemente culpa mía, no como un estándar. En la siguiente diapositiva, lo elimino y me enfoco en Jotai, MobX, Recoil y RTK. El primer lote siempre es el más lento, porque este es un momento en que el estado y la UI pasan de vacíos a datos reales. La tienda crea su estructura inicial, y la tabla construye su diseño por primera vez. Las cargas útiles aumentan, pero el rendimiento apenas cambia. Así que, la conclusión no es la transferencia de memoria. Es principalmente el trabajo de UI y suscripción en la primera actualización. Jotai mantiene los estados pequeños y por átomo. Solo computamos lo que leemos, lo que ayuda a ganar en tiempo de guardado.

Pero las cadenas derivadas pueden agregar un poco más de trabajo en la lectura en comparación con Redux y Recoil. Y en realidad esperaba que Recoil y Jotai coincidieran estrechamente, porque ambos usan estado de estilo atom. En cambio, Recoil a menudo se sitúa cerca de Redux. Recoil construye un gráfico de dependencia de átomos y selectores y valores derivados en caché. La caché ayuda a la lectura pero agrega algo de sobrecarga en el tiempo de guardado, especialmente por primera vez. RTK pasa por reductores y a menudo usa emur, lo que hace que las actualizaciones inmutables sean más fáciles, pero agrega trabajo al guardar. Podría ser la razón por la que es más lento que Jotai.

Redux también estrecha la suscripción, por lo que solo los componentes correctos se renderizan, lo que puede prestarle nuevo Recoil en la práctica. MobX es muy detallado y reactivo. Solo se renderizan las rutas que observas, pero cuando muchos observables cambian, a la vez el guardado puede encadenarse a través de valores calculados y reacción. Mi aplicación está estructurada alrededor de selectores de átomos y reductores de segmentos que favorecen a Recoil, Jotai, y RTK. MobX puede brillar con tiendas de dominio de objetos observables. Aquí se paga un pequeño impuesto de estructura. Por supuesto, el resultado depende mucho de la estructura del componente y de cómo estoy obteniendo datos.

Así que, este es un benchmark de mi aplicación, no un ranking epsilon. Ahora, probemos las interacciones del usuario. Aquí, hago clic en un candidato en cualquier gráfico. El mismo candidato debería destacarse en todos los demás gráficos. Y la vista lateral se abre con detalles del candidato. El objetivo es simple. Actualización de estado, propagación, cada suscriptor refleja el mismo candidato seleccionado. Así que, clic, todos los gráficos destacados, vista lateral abierta. Tan pronto como hago clic, inicio un temporizador en OnClick antes de que ocurra cualquier renderizado. Medimos solo la propagación del estado. No el tiempo de renderizado de React, no el tiempo de pintura del gráfico.

Esos pueden tomar, de hecho, 8,000 milisegundos en grandes conjuntos de datos. Así que los dejamos fuera. Despachamos el candidato y detenemos el temporizador solo cuando todos los suscriptores del gráfico reciben el mismo candidato seleccionado y la tienda de vista lateral se actualiza con la información del candidato. Repetimos esto muchas veces y calculamos un promedio por biblioteca. Aquí, la diferencia existe. Pero son pequeñas. Todo está alrededor de 5, 4 milisegundos. Y en este caso de uso, el tiempo de renderizado es mucho mayor. 8,000 milisegundos. Así que aquí, cambiar de bibliotecas no mejorará mágicamente el rendimiento. El costo no está en la representación. El costo está en la representación, no en el estado.

Veamos otro experimento. Aquí, abrimos la página del inspector con gráficos enlazados en serie que rastrean la misma optimización. A medida que nuevos lotes llegan desde el back end, cada gráfico agrega nuevos puntos y se mantiene sincronizado en toda la página. En el momento en que un lote aterriza, necesitamos actualizar rápidamente todos los gráficos visibles. Este caso de uso, estresa la propagación. Una actualización entrante tiene muchos suscriptores de gráficos. Y deberíamos mostrar nuestra optimización en progreso en la vida real.

Así que, abrimos la página del inspector con múltiples gráficos enlazados. Suscribimos la página a lotes de optimización en vivo. Recibimos lotes para una o más optimizaciones. Cada lote se inyecta en la tienda del cliente. Luego, los gráficos que dependen de esa serie obtienen la nueva porción. Evitamos datos históricos y tratamos de agregar en lugar de reemplazar matrices. Agregamos los nuevos puntos y mantenemos los gráficos sincronizados. Comenzamos en el controlador del cliente cuando se recibe un lote. Detenemos cuando cada gráfico objetivo señala. Se renderizaron los nuevos puntos. Misma comparación de ejecución.

Todas las bibliotecas en optimización idéntica. Medir con rendimiento. Ahora, incluya fechas almacenables. Aquí están los resultados. Estamos midiendo el tiempo después de que se completa la obtención de un nuevo lote.

Y gráficos representando nuevos datos. Tenemos menos datos para guardar que en el primer experimento. Pero más lugares para actualizar y ver datos al mismo tiempo. Nuestra clasificación, Recoil, MobX, GeoTie, alrededor de dos segundos.

Zustand, FGK, alrededor de cuatro segundos. Nuestra interfaz de usuario fue originalmente modelada para selectores de estado de átomos de Recoil. Así que, son beneficios naturales. Los selectores de átomos de Recoil y los átomos de GeoTie evitan renderizados en bruto actualizando solo dependencias. El gráfico observable de MobX desencadenó reacciones dirigidas. RTK, Zustand podrían necesitar más trabajo para reducir la brecha entre de reducir la brecha con selectores memorizados, suscriptores, segmentación cuidadosa del estado, y actualizaciones por lotes. Los modelos de tienda global dependen de actualizaciones inmutables y selectores.