Generic Jobs/Entities

I'm using generic abstract base classes a lot because our code base needs to do work on loads of different types. We have huge lists of these types stored in scriptable objects and I was wondering what the performance impact of using generics a lot is on the job system, ecs and the burst compiler. I haven't seen any discussion on the topic and got curious.

 

I can't speak to the performance, but base classes and extensible object types seem to run counter to data-oriented design, which is the orientation ECS is based on.

 

Would that also be true for generic interfaces?

 

I believe so. I'm not an expert, but Richard Fabian is. I'd recommend Richard Fabian's Data-Oriented Design. There's a free, online version at http://www.dataorienteddesign.com/dodbook/

 

Hi, we have some experience with this in our team. As for generic ComponentData types, everything works fine, although we are not using entity serialization so I can't vouch for that working. There are some things that scale (meaning time-complexity) with the number of types though, and using generic types is an easy way to multiply this number quickly so this is one thing to watch out for. We also use a lot of generic jobs (we have some jobs with fully-qualified name length of 40 000 characters), and the Burst compilation slows down considerably (meaning the compilation time, not speed of generated native code). We also had to do some hacks to compile some jobs (string length limit reached, etc.). For the most part, you can abuse generics for a kind of compile-time polymorphism with Burst, a lot like templates in C++.