Más allá de las listas virtuales: Cómo renderizar 100K elementos con 100s de actualizaciones/seg en React

Buenos días a todos. Mi nombre es Michel Vestrater. Trabajo en Facebook, creo, porque podría tener otro nombre hoy. Pero es bueno estar aquí y es muy bueno ver todos sus rostros sin ver también su dormitorio y su ropa y su tazón de avena vacío. Gracias por tenerme.

Actualmente estoy trabajando en un proyecto llamado Flipper que es una plataforma de código abierto que es utilizada principalmente por desarrolladores móviles. Y voy a hablar sobre cómo optimizar la representación de tablas realmente grandes. Y en esta charla, hablaré un poco sobre Flipper. Encontraré una aplicación realmente útil de bitcoins y les mostraré una biblioteca de código abierto.

Entonces, en primer lugar, hay una herramienta llamada ADB que se utiliza para debugging aplicaciones móviles. Y si ejecutas, por ejemplo, ADB log, simplemente genera muchos datos. Puede generar fácilmente hasta 100 líneas por segundo o algo así. Y entonces estamos trabajando en Flipper, una herramienta que te permite inspeccionar diseños en un dispositivo móvil y ver las solicitudes de red de tu aplicación React Native y así sucesivamente. Sin embargo, nos vamos a centrar en esta charla en una característica específica, que son los registros. Y los registros, básicamente muestran la misma salida que acabas de ver de ADB, excepto que lo hemos analizado para que pueda ordenar un filtro.

Ahora, la implementación original que teníamos no es muy fluida. Como que empieza un poco, no mantiene realmente el ritmo, y especialmente si aplicas algunos filtros, se ralentiza. Y además, no envuelve correctamente las líneas, lo cual es realmente molesto si usas registros. Así que pensamos que esto es demasiado lento, y en realidad lo que detectamos, incluso en las compilaciones de producción, si el filtro es un poco complicado, y ya tienes 100,000 líneas de registro en él, entonces una sola pasada de renderizado de nuestro componente React podría consumir fácilmente hasta 250 milisegundos, por lo que terminas con cuatro fotogramas por segundo, lo cual es realmente molesto.

Y entonces pensamos que necesitábamos una mejor implementación, y construimos una. Y esta es la nueva versión, que es mucho más suave, pero que realmente mantiene el ritmo con los datos que llegan a través de ADB, e incluso si estás filtrando, apenas afecta al rendimiento. Y también mejoramos mucho la interacción del usuario, así que tenemos enlaces que se resaltan, las líneas se ajustan automáticamente si cambias el tamaño de la ventana, ese tipo de cosas. Así que hicimos los datos mucho más ricos, e incluso añadimos cosas como poder ordenar en cualquier columna que quieras.

¿Y cómo afectó esto al rendimiento? Resulta que el rendimiento de la nueva implementación fue diez veces más rápido. Y vimos que en Facebook, medimos cuál es el rendimiento, cuántos fotogramas dejamos caer, cuál es la carga de la CPU para nuestros usuarios, y básicamente vimos una caída de fotogramas diez veces menor, y un uso mucho más lento de la CPU. Y si miras el perfil en Chrome, podemos explicar eso. Y entonces las dos secciones de la izquierda son básicamente la situación antigua donde hay mucha CPU en marcha y la mayoría de ella es amarilla. Y el amarillo significa que esto está ejecutando JavaScript código, nuestro código de Flipper. Y en la nueva situación, todavía hay mucho uso de la CPU pero se gasta de manera diferente. Ya no se gasta en la parte amarilla, ya no en el scripting.

Ahora está realizando mucho diseño y estilizado, y eso significa que está generando muchos más fotogramas por segundo. Entonces, en resumen, el morado es bueno. El amarillo es malo. Entonces, ¿cómo hicimos eso? Y para explicarlo un poco, voy a mostrarles una pequeña aplicación de demostración que transmite muchas transacciones de Bitcoin para que al menos pongamos todos esos ciclos de CPU desperdiciados en buen uso. Y no soy tan valiente como Sarah, así que simplemente lo pregrabé. De todos modos.

Entonces, comencemos con la base. ¿Qué hacemos? Establecemos una conexión WebSocket con Coinbase y comenzamos a escuchar tres diferentes tasas de cambio. Y para cada nuevo mensaje que llega, recogemos las devoluciones de llamada. Y los data básicamente se ven un poco así. Solo un intercambio de una cierta tasa. Entonces, lo que sucede aquí es que realmente no estamos representando nada. Lo siento. Estoy estropeando esto. Entonces, lo que Sarah puede hacer con la codificación en vivo, yo puedo hacerlo con un video. ¿No es asombroso? Entonces, la idea aquí es que aún no representamos nada. Y si comienzas a transmitir, verás que básicamente estamos recibiendo mil elementos por segundo. La CPU no está haciendo nada porque no hacemos nada con ella. Pero esta es nuestra línea de base. Entonces, conceptualmente, esto es lo que está sucediendo. Entonces, vamos a mezclar React.

Entonces, tenemos nuestros pequeños componentes base y comenzamos a introducir un estado en el que almacenamos todas las filas que llegan. También comenzamos con un conjunto base de diez mil filas para tener al menos algo. Y cada vez que llega cualquier fila, actualizamos el estado, asignamos un nuevo array y lo colocamos allí. Y luego, si hay un filtro activo, lo aplicamos al conjunto de datos. Y de manera similar, si el usuario quiere ordenar las secciones por precio, aplicamos una función de clasificación. Entonces, mapeamos todas las filas y las representamos una por una. Entonces, si ejecutas esto... Oh, creo que la presentación se rompió al moverla a un portátil. De todos modos, eso es lo que sucede si lo cambias en el último momento.

Entonces, si renderizas esto, se renderiza bastante bien siempre que los data sean estáticos. Pero tan pronto como empezamos a filtrar realmente empieza a ralentizarse. Ahora tenemos cinco fotogramas por segundo y la CPU en la parte inferior está al máximo. Y si empezamos a habilitar la transmisión, en realidad somos capaces de procesar como tres nuevos registros por segundo y eso es porque estamos renderizando todas esas 10,000 filas una y otra vez.

Esto es realmente lento, no es una buena idea. Lo obvio que hacemos en este tipo de situaciones es aplicar virtualización. En este punto, normalmente hay algunas personas que se preguntan, ¿por qué estás renderizando 10,000 filas en primer lugar? Eso no es una buena user experience. ¿Por qué mostrar tantos data? Y en mi experiencia, eso suele ser una especie de excusa barata para evitar un problema difícil. Y es muy sencillo de demostrar. Tomemos un terminal. Hace una década, solía tener una cantidad fija de líneas de desplazamiento, como quizás 1,000. Y lo que hace cada ingeniero es ponerlo en ilimitado. Queremos tener todas esas líneas a nuestro alcance cuando hacemos una instalación de NPM. Queremos desplazarnos muy rápidamente, buscar, filtrar. Y estoy bastante seguro de que la mayoría de los ingenieros dejarían ese trabajo si alguien sugiriera que el terminal debería ser paginado. Y lo mismo ocurre con muchos paneles de control que muestran una gran cantidad de data comerciales, gráficos, filas que se actualizan con información de acciones en realtime. Tener miles de puntos de data con cientos de actualizaciones por segundo no es realmente tan extraño en absoluto.

Entonces, lo típico que hacer en este punto es aplicar virtualización. Hay un montón de buenas bibliotecas por ahí para React, React Window, Virtuoso, pero la mejor que encontré es React Virtual de Tanner Lindsay. Y es realmente buena. Básicamente, el uso es bastante sencillo. Te proporciona un hook, pero también soporta el envoltorio de filas. Y la idea es que llamas a este useVirtualHook, le das la cantidad de data que quieres renderizar y un contenedor que se utiliza para los cálculos de tamaño. Y luego te devuelve un montón de elementos para mapear, y para cada uno de ellos, aplicas un poco de estilo. Es un montón de estilo, pero es realmente sencillo construir esto.

Así que pongamos esto a prueba. Entonces, de nuevo, en el conjunto de datos estático, se desplaza muy fluidamente. Y lo interesante es que, una vez que empezamos a transmitir los data, ahora podemos, en lugar de tres, cuatro elementos, podemos renderizar - podemos recibir un par de cientos de elementos antes de que empezamos a ralentizarnos. Ahora, el filtrado sigue siendo caro. Como, una vez que aplicas el filtrado y la clasificación, realmente ves la cantidad de elementos que puedes procesar en el ínterin disminuir.

Y también estamos aprovechando al máximo la CPU. Entonces, React Virtuall resuelve el problema para nosotros si tenemos un conjunto de datos estático y necesitamos poder desplazarnos muy rápido. Ese es el problema que resuelve. Sin embargo, esto no resuelve nuestro problema. Porque esa no es la única parte que es costosa, la representación. También es el procesamiento de data. Si cada vez que recibimos un nuevo elemento, tenemos que mapear todo el conjunto de datos, filtrarlo de nuevo. Y si la clasificación está activa, también tenemos que reordenar el conjunto de datos. Ahí es donde realmente se va el rendimiento.

Entonces, la virtualización ya la teníamos en el primer ejemplo que mostré. Y aún así, todavía teníamos 250 milisegundos por representación solo por todo el procesamiento que se lleva a cabo. Y hay algunos trucos que la gente suele aplicar. Como, podríamos memorizar las filas filtradas. Pero eso realmente no ayuda. Eso solo ayuda si el filtro cambia de vez en cuando. Pero no si tus filas están cambiando todo el tiempo. Si tienes docenas de actualizaciones que tienes que procesar, entonces tu memo nunca va a tener un acierto positivo en la caché. Y de manera similar, puedes rebotar, lo que asegura que al menos tu aplicación tipo de se mantiene utilizable. Pero no disminuye el rendimiento de una sola representación. Y te permite ir más allá de esos cuatro fotogramas por segundo en nuestro caso de uso. Entonces, ¿qué podemos hacer de manera más inteligente?

Una cosa que podemos hacer de manera más inteligente es no filtrar todo el conjunto de datos que tenemos. En realidad, ya sabemos para cada elemento si cumple o no los criterios de filtro. Solo necesitamos filtrar los data que llegan, no los data que ya tenemos. Así que hagamos eso. Así que lo primero es que no vamos a ordenar nuestras filas en estado, lo que causaría una representación cada vez que lo cambiamos, pero ordenamos en ref. Y el estado que vamos a contener son solo las filas visibles. Ahora, si llega un nuevo evento, lo aplicamos al conjunto base, y luego también verificamos si coincide con el filtro actual. Si coincide con el filtro actual, entonces también actualizamos el conjunto de filas visibles. Y luego hay una cosa más que hacer, es que cada vez que el criterio de filtro en sí entonces necesitamos volver a filtrar todo el conjunto, pero ahora ese es el caso excepcional. Y entonces pongamos esto a prueba.

Así que recuerda, lo importante es que solo actualizamos el estado si el elemento coincide con el filtro. Así que en el caso base, nuestro performance es el mismo que en el ejemplo anterior. Sin embargo, si empezamos a filtrar, ahora el performance aumenta en el sentido de la cantidad de nuevos elementos que podemos procesar. Porque ahora en 2 de cada 3 de las transacciones, no causamos una renderización. Así que dejamos mucha más capacidad de CPU disponible para procesar ese WebSocket entrante. Así que, eso ya es una buena mejora. Esto mueve nuestro costo de filtrado del orden de n a una sobrecarga constante.

¿Podemos hacer lo mismo para la clasificación? Y la respuesta es sí. También podemos hacer exactamente lo mismo para la clasificación. ¿Cómo lo hacemos? La idea básica es que aprovechamos el hecho de que sabemos que lo que estamos renderizando ya está ordenado, si estaba ordenado antes. Así que cuando llegan nuevos data, no necesitamos reordenar el conjunto completo. En su lugar, podemos utilizar una pequeña utilidad de Lodash. Y encontrar utilizando sorted last index by, el binario, el índice de inserción en el que tenemos que insertar nuestra nueva fila. Y entonces solo hay una búsqueda binaria en lugar de una clasificación completa en los data. Así que pasan de básicamente N log N a log N. De nuevo, lo mismo se aplica para si la clasificación en sí cambió, tenemos que hacer el conjunto completo, pero, de nuevo, este es el caso menos común.

Así que pongamos esto a prueba. Y recuerda, lo crucial aquí es que en lugar de ordenar el conjunto completo, hacemos una búsqueda binaria para encontrar la posición de inserción. Y así, de nuevo, procesamos los data. Empezamos a seguir. Empezamos a filtrar. Y tenemos un buen performance. Y ahora habilitamos la clasificación. Así que ahora el conjunto de data está ordenado. Y sin embargo, no afecta realmente a nuestro performance. Y normalmente la clasificación es realmente costosa. Ahora no está impactando tanto. Así que ahora optimizamos el filtrado, optimizamos la clasificación. ¿Podemos hacerlo aún mejor que esto? Y la respuesta es sí. También podemos empezar a ventanear los data que procesamos.

Ahora suena un poco controvertido porque ya estamos aplicando ventaneo, pero solo estamos aplicando ventaneo a la renderización. Pero en realidad, si lo piensas, podemos aplicar el ventaneo anteriormente en el momento en que procesamos los data. Así que cuando se agrega una nueva fila, pero se agrega efectivamente fuera de la vista actual, ni siquiera necesitamos desencadenar una renderización. Incluso si coincide con el filtro y encuentra el índice de inserción. Si después de eso encontramos que no está dentro del viewport, en realidad no hay necesidad de causar que react vuelva a renderizar y haga esos cálculos de fertilización. Así que apliquemos también ese truco.

Así que ahora no tenemos ningún estado. Y para capturar lo que estamos viendo actualmente, introducimos una ventana que simplemente comienza el conjunto visible de filas y utilizamos un truco, actualización forzada, para forzar una renderización de React cuando queramos. Y si no queremos renderizar, React nunca volverá a renderizar.

Ahora lo siguiente que hacemos es después de cada renderización, almacenamos el rango que renderizamos, el rango que obtuvimos de React virtual, lo siento. Y luego verificamos cuando encontramos el índice de inserción de una fila, verificamos si está dentro de Luego verificamos React para renderizar, y de lo contrario no.

Ahora hay un caso de excepción, y eso es que una vez en las cien filas, todavía vamos a desencadenar una renderización, y eso es para asegurarnos de que nuestra barra de desplazamiento sigue creciendo si más data llega, incluso si todos los data llegan fuera del viewport actual. Así que probemos esto. Así que empezamos a transmitir, y ves que, como, procesamos muchos data, especialmente si no seguimos, porque entonces todos los eventos ocurren fuera de la ventana. Cada cola, todavía tenemos el mismo performance que antes, pero sin nuestra cola, todo, casi todo se añade fuera de la pantalla, así que, apenas usamos cualquier CPU. Esta es también la primera vez que la CPU realmente cae por debajo del uso máximo.

Entonces, ahora tenemos una tubería más larga, filtramos, iniciamos, verificamos si la actualización realmente aparece dentro de la ventana visible, y solo si todo eso es cierto, entonces hacemos que React se renderice. Así que, ahora añadimos mucha lógica, y solo fue para añadir. ¿Cómo lidiamos con las actualizaciones? ¿Cómo lidiamos con las inserciones? ¿Cómo lidiamos con las eliminaciones? Y la solución que les he mostrado hasta ahora, la hemos generalizado en un paquete. Se llama Flipper Datasource. Se mantiene por ahora dentro del repositorio de Flipper en GitHub. Pero puedes usar este paquete de inmediato. Y la idea básica es que todas las demás operaciones básicamente siguen el mismo patrón. Una actualización o una eliminación no es significativamente diferente de una inserción. Esos cuatro pasos son básicamente una tubería que es donde describimos la operación inicial. Por ejemplo, añadiendo un elemento. Y luego aplicamos la ordenación y simplemente transformamos la descripción de la operación. Así que una operación de añadir se convierte en una inserción en una posición diferente con el mismo elemento. Y luego también tenemos una operación de inversión en caso de que estemos ordenando al revés. Y luego decidimos si esta operación termina en la ventana. Así que primero transformamos la operación sin pensar en la renderización en absoluto. Y las demás operaciones también son realmente fáciles de expresar en estos mismos términos. Simplemente pasan por la misma tubería. Así que vamos a refactorizar nuestro ejemplo para aprovechar el paquete de datos de Flipper. Así que eliminamos toda nuestra lógica personalizada, nuestros efectos. Todavía tenemos los mismos criterios de vista. El usuario todavía tiene las mismas características. Solo vamos a conectarlo de manera diferente. Así que ya no necesitamos React Virtual. Eso está abstraído. Eliminamos todo eso de la renderización, que está por aquí. Ahí vamos. Y luego simplemente importamos algunas cosas de los paquetes. Así que importamos el crear data source, que crea el data source y mantenemos una referencia a él. Y lo único que hacemos cuando llega un nuevo evento es llamar a append, y eso almacena el evento en el data source. Entonces, cada vez que el usuario cambia los criterios de filtro o de ordenación, simplemente actualizamos la configuración de la vista del data source.

Ese data source, lo pasamos al renderizador de data source virtual. Y con eso, básicamente tenemos lo mismo que lo que hemos construido hasta ahora en esta demostración. Es solo ahora unas pocas líneas de code.

Entonces, pongamos esto a prueba. De nuevo, empezamos. Empezamos a seguir. Haciéndolo difícil. Y empezamos a filtrar. Y en realidad vemos que, como, el performance es realmente bueno ahora. Aunque esto es solo una compilación de debug de React, se mantiene fácilmente en términos de CPU.

Entonces, esto está implementado de manera un poco más eficiente de lo que hemos hecho hasta ahora. Pero ahora nuestra CPU apenas está sudando. Aunque estamos agregando casi mil registros por segundo y los estamos ordenando y filtrando. Y para hacerlo aún más difícil, podemos comenzar con un gran conjunto de datos. Entonces, en lugar de 10,000 elementos, comencemos con 100,000. De nuevo, hicimos lo mismo. Y lo que notaremos es que, esto lo hace un poco más caro. Entonces, el uso de la CPU es un poco más alto. Pero aún así, se mantiene bien. Así que no estamos maximizando en CPU y JavaScripting. Lo que significa que la renderización, la tasa de fotogramas, se mantiene estable a 50 fotogramas por segundo.

Entonces, básicamente, esto es todo lo que quedaba para hacer que esta demostración fuera eficiente. Y eso es lo que hace el paquete de data source de Flipper. No es perfecto todavía, pero funciona muy bien en esos casos. Lo usamos para alimentar todas nuestras vistas críticas en un flipper. Puedes simplemente mirar el code fuente. Está en nuestro repositorio. Y hay algunas ideas futuras. Como, el mismo mecanismo podría usarse, por ejemplo, para alimentar gráficos. Hay una pequeña demostración de ello.

Pero hay muchas posibilidades. Porque, como muchas visualizaciones, siguen este filtro, ordenan y ventanean. Así que, pruébalo. Házmelo saber qué piensas. Si tienes alguna pregunta, no dudes en preguntar. Gracias.

Esa fue una charla increíble. Muchas gracias. Aplaudamos de nuevo por él. Muy bien. Así que, tenemos algunas preguntas que llegaron durante la charla y simplemente te las haré y luego lo que haremos es al final, escogerás tu pregunta favorita y esa persona puede obtener una camiseta. Así que, simplemente iré en el orden en que han sido votadas hasta ahora.

La primera es, ¿cómo funciona el ordenamiento incremental con datos no lineales en términos de tener que volver a calcular el conjunto de datos ordenados, un conjunto entrante no ordenado de fechas, por ejemplo? Entonces, déjame ver si entiendo correctamente la pregunta. Entonces, cómo funciona el ordenamiento es que se basa en una función de comparación donde puedes, como, tener una salida de ordenamiento estable. Por ejemplo, puede haber una fecha de hecho. Y solo se compara en relación con otros elementos. Entonces, los datos entrantes no tienen que estar ordenados en absoluto. Como, puedes ordenar en tantos criterios como sea posible. Siempre que tengas una función de ordenamiento estable, eso funciona. Perfecto.

Y otra pregunta es ¿cómo maneja la lista virtual la altura de fila dinámica? Esa es una muy buena pregunta. He leído el código fuente de eso un rato. Entonces, lo que hace, ejecuta los elementos, luego los mide y almacena las mediciones y usa eso para compensar los siguientes elementos. Pero porque, como, la altura se memoriza por fila, al menos mientras el ancho no cambie, eso funciona en la práctica realmente bien. Tienes que dar una función heurística para la altura base de edición. Pero luego eso comienza a ajustarse. Curiosamente, eso no es realmente notable. Genial. Y otra más. Gracias por la gran charla.

¿La fuente de datos de Flippa ya tiene una API para la virtualización en dos dimensiones, por ejemplo, para cuadrículas? No. Actualmente solo realiza virtualización unidimensional. Y también lo que creo que es realmente interesante agregar en el futuro es agregar submuestreo a la abstracción. Eso lo haría realmente útil para trazar gráficos si pudiéramos submuestrear dinámicamente los eventos que llegan.

Genial. ¿Has intentado optimizar el auto-zebra-rendering? Entonces, por ejemplo, filas oscuras y claras una tras otra. No, no lo intenté. Pero eso no debería... Lo que obtienes de useVirtual es solo una matriz con elementos. Por lo tanto, puedes usar el índice del elemento de la matriz para el zebraing, en lugar de asociarlo con los data. Eso debería funcionar bien. A menos que realmente te importe que la fila específica siempre sea gris y la otra siempre blanca. Pero no creo que ese sea generalmente el caso.

Bien. Ahora, hay tantas preguntas, no podremos llegar a todas. Así que solo haré esta última para terminar, porque esta es una de mis favoritas. ¿Cuántas noches en vela hubo, llegando a esta solución final? En realidad, no tantas. La razón es que quería construir esto hace años, pero nunca tuve una excusa sólida, hasta que comencé a trabajar en Flipper. Y así Flipper, para responder a tu pregunta, sí, lo usamos en la vida real en Flipper. Así que puedes descargar Flipper y probarlo. Así que no dio tantas noches en vela. Genial, muchas gracias. Ahora sé que había más preguntas, así que puedes pasar el rato en la sala de discussion del orador en persona, que estará a la vuelta de la esquina justo fuera de la puerta, y si estás en una audiencia remota, puedes ir al spacial react advanced, eso es bit.ly forward slash spatial react advanced, para unirte a la conversación. Pero tienes una gran decisión que tomar. ¿Cuál fue tu pregunta favorita de todas las que viste? Esa sería la de las noches en vela. Noches en vela. Eso es muy amable de Gareth. Una muy buena pregunta, ¿verdad? Entonces Dave o DJ Amy, van a tener una camiseta. Si estás aquí en persona, solo ven al frente. Si estás en línea, nos pondremos en contacto contigo. Todos aplaudan por él, y definitivamente revisen su charla.