Ce que j'ai appris après une migration DOTS/ECS
Nous avons migré une partie d'un projet en production vers ECS et le temps de frame a chuté de 34 %. Mais le gain n'est pas venu d'où on l'attendait.
Pourquoi migrer
Nous avions près de 3 000 entités mobiles à l'écran en même temps, et la même chose trônait en tête du profileur à chaque fois : la somme des appels MonoBehaviour.Update et les défauts de cache qu'ils provoquaient.
L'objectif n'a jamais été de tout passer en ECS. Nous n'avons migré que ce qui était nombreux, uniforme et dense : projectiles, unités de nuée, logique de particules.
Le vrai gain est dans la disposition mémoire
Tout le monde parle de Burst et du SIMD. Dans nos mesures, la différence ne venait pas de là ; elle venait du fait que les données étaient contiguës en mémoire.
L'écart entre lire 3 000 objets un par un dans le tas et lire 3 000 positions séquentiellement dans un tableau a produit jusqu'à 8× de différence de temps pour des calculs identiques.
Le coût d'une architecture hybride
Comme nous ne sommes pas passés entièrement en ECS, il a fallu faire le pont entre deux mondes. Ce pont a représenté bien plus de travail que prévu.
Mon conseil : tracez la frontière clairement dès le départ. Quels systèmes vivent côté ECS, lesquels restent classiques, et le flux de données entre eux est-il unidirectionnel — décidez avant d'écrire du code.
Quand ça n'en vaut pas la peine
Si votre nombre d'entités ne dépasse pas quelques centaines, la complexité apportée par ECS l'emporte sur le gain. Si l'équipe ne connaît pas ECS, comptez aussi le coût d'apprentissage.
J'utilise un seuil simple : si plus de 500 objets exécutent le même comportement et se mettent à jour chaque frame, la migration vaut le coup.