Lo que aprendí tras una migración a DOTS/ECS
Migramos parte de un proyecto en producción a ECS y el tiempo de frame bajó un 34 %. Pero la ganancia no vino de donde esperábamos.
Por qué migramos
Teníamos cerca de 3.000 entidades en movimiento a la vez en pantalla, y en el profiler siempre aparecía lo mismo arriba del todo: la suma de las llamadas a MonoBehaviour.Update y los fallos de caché que provocaban.
El objetivo nunca fue pasarlo todo a ECS. Solo migramos lo numeroso, uniforme y denso: proyectiles, unidades de enjambre, lógica de partículas.
La ganancia real está en la disposición de memoria
Todo el mundo habla de Burst y SIMD. En nuestras mediciones la diferencia no vino de ahí, sino de que los datos estuvieran contiguos en memoria.
La distancia entre leer 3.000 objetos uno a uno del heap y leer 3.000 posiciones secuencialmente de un array produjo hasta 8× de diferencia de tiempo con las mismas operaciones.
El coste de una arquitectura híbrida
Como no pasamos del todo a ECS, tuvimos que tender un puente entre dos mundos. Ese puente dio mucho más trabajo del previsto.
Mi consejo: traza la frontera con claridad desde el principio. Qué sistemas viven en el lado ECS, cuáles siguen siendo clásicos y si el flujo de datos entre ellos es unidireccional: decídelo antes de escribir código.
Cuándo no compensa
Si tu número de entidades no pasa de unos cientos, la complejidad que trae ECS supera la ganancia. Si el equipo no conoce ECS, cuenta también el coste de aprendizaje.
Uso un umbral sencillo: si más de 500 objetos ejecutan el mismo comportamiento y se actualizan cada frame, merece la pena migrar.