Hi guys! I've made recently a handy pool manager for unity3d and would like to share it with you. 
An ultra fast and lightweight object pool manager with zero allocations and customizable prepopulate feature. You can group uploading objects in chunks and set how many frames you need for uploading to reduce allocation spikes. Uses Unirx extension and based on object instance ids. You can pool prefabs without any extra components and can mix different prefab types in one pool.
Github
sweet I'll try this out soon and let you know how it goes, I've always needed one but never spent much time getting into it because my games have yet to reach that far in development lol
Nice attempt.
I'd be careful about using that Singleton. Apart from the fact that it is a Singleton with those inherent issues of shared mutable state, that implementation includes a great way to crash or have items error into oblivion during shutting down when you return null where callers are expecting an instance. Although Unity by default treats your game object code in a single thread, the lock pattern you have is rather contentious for multithreaded code, particularly if you have many threads attempting to read the object at once.
As for the pools, I'm not sure why you write that there are zero allocations. It looks like a pool Spawn can not only add to collections, but can also create entirely new stacks of objects. Adding to dictionaries is a potentially slow operation, so I'm not sure why you chose that container.
While it is a good attempt, I think I'd rather go with a flat container and a live/dead flag. And I'd recommend avoiding that Singleton, and avoiding shared mutable state in general.
3 hours ago, frob said:Nice attempt.
I'd be careful about using that Singleton. Apart from the fact that it is a Singleton with those inherent issues of shared mutable state, that implementation includes a great way to crash or have items error into oblivion during shutting down when you return null where callers are expecting an instance. Although Unity by default treats your game object code in a single thread, the lock pattern you have is rather contentious for multithreaded code, particularly if you have many threads attempting to read the object at once.
As for the pools, I'm not sure why you write that there are zero allocations. It looks like a pool Spawn can not only add to collections, but can also create entirely new stacks of objects. Adding to dictionaries is a potentially slow operation, so I'm not sure why you chose that container.
While it is a good attempt, I think I'd rather go with a flat container and a live/dead flag. And I'd recommend avoiding that Singleton, and avoiding shared mutable state in general.
Thanks for the feedbacks : )
I usually do not use singletons everywhere though I do not consider them as evil in game dev / small projects. It's just a tool. I have my toolbox system to grab any services/managers I need.
As example
But I don't want to force people to write code in my style. It's easy to remove singleton from pool manager and make it as service for example or use it as you want.
Cheers!
