Caveat of using ObjectPool if specifying too many objects?

too many in the sense!! approx?

say you instantiate 1 million of the same object in the pool

:D well 1$$anonymous$$ objects... that would take some time to create... beside that just think of how big a single object is. A GameObject has at least around 100 bytes (it has a name (string), tag (string), some references, Components, whatever...) so 1$$anonymous$$ objects in this case would take up 100$$anonymous$$B. If you have an array (you propably have) that stores the references you have another 4$$anonymous$$B (a reference is usually 4byte[32bit]).

I don't think you want 1 million objects in your game, do you? You always have to think about what's practical. Instantiate enough that you don't run out of objects but just as much as needed.

Example: If you have a gun in your game that fires bullets. The bullets have a max lifetime of 5 sec. Your firerate is 5 shots per sec.

5 * 5 == 25 that means if you fire non-stop you need 25 bullets at the same time. It makes no sense to Instantiate 1000 bullets. 25 is probably not enough. Due to small ti$$anonymous$$g errors you might need sometimes 26 or 27 bullets. A reserve of 5 would be enough in this case. So i would use a pool with 30 objects. If it can't be calculated that precisely you need to use a larger pool. Just double the count to be on the safe side.

Also, to add to Bunny83's post, you can always have your object recycler instantiate based on size needs using a List ins$$anonymous$$d of a standard built-in array for this purpose. Lists are still pretty fast in comparison to built-in arrays ( not Array Lists ).

I agree, it makes absolutely no sense to need to spawn that many objects into a pool, and if you are practicing the need for this then I suggest you change your thought process in this regard.