Was ich nach einer DOTS/ECS-Migration gelernt habe
Wir haben einen Teil eines Produktionsprojekts nach ECS überführt und die Frame-Zeit fiel um 34 %. Der Gewinn kam aber nicht dort her, wo wir ihn erwartet hatten.
Warum wir migriert haben
Wir hatten gleichzeitig fast 3.000 bewegte Entitäten auf dem Bildschirm, und im Profiler stand jedes Mal dasselbe ganz oben: die Summe der MonoBehaviour.Update-Aufrufe und die dadurch verursachten Cache-Misses.
Das Ziel war nie, alles nach ECS zu bringen. Wir haben nur verschoben, was zahlreich, gleichförmig und dicht war: Projektile, Schwarmeinheiten, Partikellogik.
Der eigentliche Gewinn liegt im Speicherlayout
Alle reden über Burst und SIMD. In unseren Messungen kam der Unterschied nicht daher, sondern davon, dass die Daten zusammenhängend im Speicher liegen.
Der Abstand zwischen 3.000 einzeln aus dem Heap gelesenen Objekten und 3.000 sequenziell aus einem Array gelesenen Positionen ergab bei identischer Mathematik bis zu achtfachen Zeitunterschied.
Der Preis einer hybriden Architektur
Weil wir nicht vollständig auf ECS gegangen sind, mussten wir zwei Welten überbrücken. Diese Brücke machte deutlich mehr Arbeit als eingeplant.
Mein Rat: Zieh die Grenze von Anfang an klar. Welche Systeme leben auf der ECS-Seite, welche bleiben klassisch, und fließen die Daten dazwischen nur in eine Richtung — das entscheidest du, bevor du Code schreibst.
Wann es sich nicht lohnt
Bleibt deine Entitätenzahl unter ein paar Hundert, wiegt die zusätzliche Komplexität den Gewinn auf. Kennt das Team ECS nicht, rechne die Lernkosten mit ein.
Ich benutze eine einfache Schwelle: Laufen mehr als 500 Objekte dasselbe Verhalten und aktualisieren sich jeden Frame, lohnt sich der Umzug.