If you are working on a game that constantly creates and destroys objects, you may find some performance issues, specially on lower-end hardware.
That is not to say high-end hardware may not have issues at all, since all those objects may eventually fill your system's memory. In these kinds of situations, a lot of developers recommend using object pooling. While object pooling is something you can code on your own, there are different assets in the Unity Asset Store that do that, and PoolManager by Path-o-logical Games is one of them.
In a nutshell, object pooling consists on having a "pool" of objects in your scene that can be spawned and despawned as they are needed, instead of creating new objects and destroying the objects that are no longer being used.
When you are using simple object creation, as you create objects, a portion of the system's memory is being used, but after the object is destroyed, that portion of memory may not be freed. On the other hand, object pooling allows for objects to be pre-loaded, and while this may sound like you are using more memory right off the bat, it ends up being better in the long run.
Another advantage of object pooling is related to performance issues with the creation and destruction of objects.
Every time a new object is created, you can get a quick "spike" of performance in your game.
Now, if you are constantly creating new objects, you are constantly causing more and more "spikes" of performance that may make your game run slower. While this may not be noticeable in high-end systems, it can make a big difference of performance in lower-end systems.
This issue is greatly reduced when you are spawning objects from a pool, since you are not "creating" them, but rather simply "activating" them as you need.
After that explanation, we can take a look at PoolManager.
Using PoolManager is actually pretty simple. Basically, what you have to do is add a "Spawn Pool" component to an object that allows you to create a new pool, and also add the objects you want that pool to contain (it is recommended to use an empty object to make keep track of your scene easier).
For example, if you are making a shooting game and you need to create bullets for a gun, you can figure out an average of the maximum amount of bullets (of that specific type) that will be in the game at any given point (say, 100 bullets) and then create a pool that has that amount of bullets.
Then, as the game needs the objects (in this case, the bullets), those objects are spawned from the pool and then returned to the pool after they are used (for example, after the bullet hits an enemy, a wall, or any other object).
An interesting feature in PoolManager is that you are not required to have just one type of object in a pool. You can create a pool with different game objects, which is really useful since you don't need to create a lot of pools for different kinds of objects.
However, there might be specific situations where you need to create more than one pool. For example, for one of my current projects, Color Slayer, I have four pools because it spawns a random obstacle from different kinds categories, so I found it would help me keep things more organized if I created 4 pools (one for each category) instead of only one.
Also, when the game starts and creates the pool, it may have a big impact on performance because a bunch of objects are being created right from the start.
To address this, PoolManager lets you set two different values. First, "preload delay," a value (in seconds) of how long the game should wait before it creates all those pools. And second, "preload frames," a value (in frames) of how long it should take to create all the objects. For example, if you set the preload delay to 5 and preload frames to 5, it will wait 5 seconds before it starts creating the objects, and then it will distribute the creation of objects across 5 frames. This is very useful to avoid any potential problems.
Another useful thing is that you can set it so that it doesn't destroy on a level change.
What this means is that, if you create your pool of objects right when the game starts, you can just forget about it and it will be carried across multiple levels. Because you can create as many pools as you want, you can then create per-level pools as they are needed.
For example, you can use your "main" pool to hold all the gameplay objects that will always be required (player bullets, player particle effects, etc.) and then add pools to each level that contains things from that level (specific particle effects, bullets, etc.).
As I said in the beginning, if you are using a high-end system, creating and destroying objects might be enough (although fast paced action games may be affected by the constant object creation/destruction).
However, lower-end systems will definitely benefit from object pooling.
For example, Color Slayer is a game being developed (among other platforms) for PlayStation Vita. Considering the Vita came out in early 2012 (late 2011 in Japan), you can guess it's not a powerful machine by today's standards.
When I was testing Color Slayer on the Vita, I was having a hard time trying to get past the 14 frames per second. However, after I replaced my create/destroy routines with PoolManager spawning routines, I easily got all the way to 30 frames per second (my target frame rate). While the game suffers a big hiccup right at the start when it creates all the pool objects, it remains very stable and fast during the rest of the playthrough.
Another important thing to mention is that, if you are using PlayMaker, you can find PoolManager PM actions in the Ecosystem Browser (PlayMaker's module to find custom actions created by other developers).
If you are making a game that relies a lot on object creation/destruction, you should really consider using object pooling instead of regular creation and destruction routines. If you plan to use object pooling, you should definitely give PoolManager by Path-o-logical games a try.
Find out more about PoolManager: poolmanager.path-o-logical.com