DOTS/ECS 移行から学んだこと
本番プロジェクトの一部を ECS に移行し、フレーム時間が 34% 下がりました。ただし効果は予想した場所からは来ませんでした。
なぜ移行したか
画面上に同時に 3,000 近い可動エンティティがあり、プロファイラーの上位には常に同じものが並んでいました。MonoBehaviour.Update 呼び出しの総和と、それが引き起こすキャッシュミスです。
すべてを ECS にする意図は最初からありませんでした。数が多く、均質で、密集しているものだけを移しました。弾丸、群れユニット、パーティクルのロジックです。
本当の効果はメモリ配置にある
誰もが Burst と SIMD の話をします。私たちの計測では差はそこから来ませんでした。データがメモリ上に連続して並ぶことから来ていたのです。
3,000 個のオブジェクトをヒープから個別に読むのと、3,000 個の位置を 1 つの配列から順に読むのとでは、同じ計算でも最大 8 倍の時間差が出ました。
ハイブリッド構成の代償
完全な ECS 化をしなかったため、2 つの世界を橋渡しする必要が生じました。この橋の実装が想定よりはるかに大きな作業になりました。
助言としては、境界を最初に明確に引くことです。どのシステムが ECS 側で、どれが従来側か、その間のデータフローは一方向か — コードを書く前に決めてください。
[BurstCompile]
public partial struct MoveSystem : ISystem
{
[BurstCompile]
public void OnUpdate(ref SystemState state)
{
float dt = SystemAPI.Time.DeltaTime;
foreach (var (xf, vel) in
SystemAPI.Query<RefRW<LocalTransform>, RefRO<Velocity>>())
{
xf.ValueRW.Position += vel.ValueRO.Value * dt;
}
}
}
csharpMoveSystem.cs
割に合わない場合
エンティティ数が数百を超えないなら、ECS がもたらす複雑さが利得を上回ります。チームが ECS を知らないなら、学習コストも計算に入れてください。
判断には単純なしきい値を使っています。同じ挙動をする物体が 500 を超え、毎フレーム更新されるなら移行する価値があります。