DOTS usage in production - Feedback

We've been using DOTS in production for 4 months now with a team of 3 programmers including myself. I come from a high-perf/engine background, my colleagues have a "classic" Unity background. Here are some thoughts applied to our context. This will sound critical but I absolutely love the direction Unity is going with performance by default.

1. The DOTS documentation can't be accessed easily. Googling "unity ecs documentation" points to the github samples, not the package docs. Opening the package manager to access the docs is not user-friendly.
2. There is a misconception that putting code in a `ComponentSystem` makes everything fast by default. The name being shorter than `JobComponentSystem` makes it look like the go-to choice to make things ECS. Potential solution: rename `ComponentSystem` to something like `MainThreadComponentSystem`.
3. Most of the time, the programmers transfer their Monobehaviour Update code to OnUpdate and expect the "DOTS magical compiler" (Burst) to do the job for them. Not sure what would be the solution for this, if any...
4. Several attributes are easily missed. [BurstCompile] is often forgotten even though it should be there nearly 100% of the time. Providing static analysis might help with this if Burst-compile-ready can't be made the default for job structs. Some other attributes just seem too complicated from their name even though they're used often, like [NativeDisableParallelForRestriction].
5. Unity.Mathematics and Unity.Collections provide very useful stuff in the context of DOTS, but most programmers will ignore both completely if they can use Vector3 and Dictionary<>. This goes against the concept of performance by default, since big collections of ref types are used everywhere in systems and we have tons of GC allocations. Not sure what the solution might be, maybe analysis? Making JobComponentSystem clearly the default choice would help greatly with this.
6. Leak detection and other DOTS safeguards can bring editor performance to a crawl. Maybe having the current safety settings more apparent when pressing play in editor could help.

That's all for now but I'm sure I'm forgetting some points. I'll keep this thread updated.

 

I think 2-3 stem from 1. I disagree with 2 as you can take advantage of using components within jobs(threaded work), but you can also use them outside of multithreaded scenarios and both systems utilize the main thread(in important ways).

Regarding 5, id personally love to see a document with all the old Mathf to mathematics equivalents