WebSocket‑basado en datos de mercado: la sobrecarga de Diffable Data Source y la importancia del perfilado
Una implementación de Diffable Data Source que procesaba listas completas de niveles de precio en tiempo real provocó congelamientos en la UI, y la solución fue mover los cálculos a hilos de fondo.
Durante mi tiempo en mi empresa anterior, aprendí dos lecciones que siguen siendo relevantes hoy:
- Las nuevas APIs no siempre son la opción adecuada. Un diffable data source es excelente para actualizaciones parciales, pero no para reemplazos completos.
- Las operaciones “baratas” no lo son a gran escala; siempre hay que profilizar antes de asumir.
El problema surgió al manejar datos en tiempo real con WebSockets. El requisito era mostrar todos los niveles de precio, no solo diez. En acciones, la cantidad de niveles podía variar entre 80 y 137. Durante las horas pico, la vista se congelaba: los usuarios no podían desplazarse. La falla pasó desapercibida en QA porque solo ocurría bajo carga.
Intenté usar Diffable Data Source y lo implementé con UUIDs. En lugar de enviar un snapshot, el servidor enviaba la lista completa cada vez. Cada actualización obligaba al diff a comparar todo el arreglo, generando una sobrecarga inmensa. En este caso, tableView.reloadData() resultó más rápido.
El siguiente paso fue el perfilado. Al analizar el rendimiento, descubrí que las propiedades calculadas—color de precio, formateo numérico y localización—estaban saturando el hilo principal. Con 30 paquetes por segundo, cada uno con 100 niveles, la carga se volvió inmanejable:
- Antes: 5 niveles × 30 updates/s × (formateo + color + localización) = manejable.
- Después: 100 niveles × 30 updates/s × los mismos cálculos = muerte de la UI.
La solución fue sencilla: eliminar los cálculos en propiedades computadas. Todos los valores se calculan en hilos secundarios cuando se convierte la respuesta WebSocket en datos de vista. La vista se vuelve pasiva y solo lee valores pre‑procesados.
Tras la refactorización, la aplicación soportó las horas pico sin congelarse y el desplazamiento se mantuvo fluido. Ahora, cuando aparece un problema de rendimiento, sabemos que la primera área a revisar son los cálculos en la UI.
Este caso demuestra la importancia de comprender la naturaleza de los datos y la carga que generan las APIs. No todo cambio de paradigma tecnológico garantiza mejoras; a veces, la solución más simple es la correcta.
