Is there a performance hit for thousands of disabled entities floating around?
Or does UNITY do it properly and have an array they’re placed in than your active entities and not processed unless re-enabled?
I’m just trying to wrap my head proper methodology for the software architecture of data structures in DOTS to object pool effectively.
Right now I spawn a disabled entity, then take away disabled tag.
So every single entity in my game is instantiated once at start or whenever time to load it comes along. But if UNITY improperly coded their back end, which is possible, since tag based code normally involves an array of checks cycling… Maybe there is a better way to do this.
Good to bite these things in the bud right off the bat to have a solid foundation to grow from.
There is a post buried here in the forums where Joachim says that pooling really isn’t the most efficient path in ECS. When you destroy an entity, all you are doing is removing data in the system, the destruction and instantiation issues that we had to deal with in GameObjects are not the same in DOTS (i.e. little to no garbage collection). I’m working with financial data where each day’s worth of data gets an entity representation, SPX has over 326,000 data points and I’m able to instantiate all of those within one frame. I was planning on pooling until I read that post and I built my system to destroy and instantiate the data when the user changed the day. It actually worked, it was very fast and stable…BUT it flickered (there was less than 1ms of time between the object being destroyed and the next one being instantiated but it was enough to see). I modified my code slightly so that instead of destroying all of the objects and re-instantiating them, I just destroy the extra ones (if there are too many) or I instantiate a handful of entities if there aren’t enough for the next day’s data. Works awesome and it removed the flickering. I do destroy everything and start from scratch if the user changes stock symbols though. Pooling does have its place but I don’t think there is any need to hide objects in ECS.
3 Likes
Disabled entities are simply entities with a Disabled component added to them. Since they have the Disabled component attached to them their chunks are excluded from queries unless that query specifically asks for entities that are disabled. The overhead added from keeping disabled entities around should be minimal (unless you simple have a lot of them spanning a lot of chunks). That being said, unless you use a lot of managed components (class components that require GC) I wouldn’t worry too much about pooling entities. Entities are typically light enough that you can destroy and create them without any great performance concerns.
1 Like
Unless you are instantiating complex hierarchies of entities, instantiation and destruction is actually faster than enabling and disabling. It results in less memcpy operations internally.
3 Likes
What I meant by Entity pooling is different than Gameobject pooling. Entity Pooling is’Leaving one entity always around as template entity with a DIsabled component’ I read around and they say that indeed Unity is doing it the correct way and having different memory address referencing them. So if the information I received lends me to believe that Entity Pooling that I am doing is correct.
It is pretty fun too, everything loads through Resources folder that is new. Old stuff is hard wired int. Then I just instantiate via the index, and send parameters in the method. Once my game goes up, I should maybe put this on asset store or youtube a tutorial.
You might be interested in using prefabs. Prefabs in entities are just entities with a Prefab component added to them. Again queries skip prefab entities. You can create prefab entities in the conversion process by implementing IDeclareReferencedPrefabs in an authoring component.