GC and Complexity questions about ObjectPool

Hi, I'm reading the doc of ObjectPool in Unity 2021 and have a few questions here.

1. What's extactly "Some objects" here? Should I assume that GenericPool is generating garbage in most cases?

from https://docs.unity3d.com/2021.1/Documentation/ScriptReference/Pool.UnsafeGenericPool_1.html

----------------------------------------------------------
2. If I set collectionChecks=false, does it mean that ObjectPool would not generate garbage?

from https://docs.unity3d.com/2021.1/Documentation/ScriptReference/Pool.ObjectPool_1.html

----------------------------------------------------------
3. ObjectPool is a stack based pool, what's the complexity of the collection checks? I mean, I barely see anybody implement a hashset inside a stack based thing, but it's even worse to have an O(n) checks, right?

 

Isn't the object pool supplied as source code in the package? I think you can just go in and reason directly about all your questions above.

Beware though: it could be rewritten in the future. It's not your code, so don't rely on undocumented details.

If you need a highly-specific behavior, just write it yourself, or crib it from the object pooler, and then it's your code.

 

I think you have a way to complex view on that class It's a really tiny class. Just as Kurt said, the reference code is in the reference repository. The UnsafeGenericPool is actually just a wrapper on the first one. This should already answer your second question since the unsafe variant just uses the ObjectPool class with the collectionChecks disabled.

About your first question, no, most objects do not allocate any garbage as the default comparer would be used to compare two instances. For objects that's usually just a reference comparison. If the two instances you compare are not literally the same reference, they would not be equal. That's the default. However a class can implement its own comparison methods which may allocate memory when you compare two objects. If you don't use the pool with such objects, the allocation thing should not be an issue. Keep in mind that even default comparers usually allocate memory, but only once at the first use. So technically it allocates memory, but does not generate garbage as this is only released when the program ends.

About your last question: Yes, the collection checks has a complexity of O(n) where n is the number of inactive objects in the pool. It simply uses Stack.Contains to check if the object is already in the pool. Though I don't think the collection checks would have a huge impact unless you're creating a bullethell game where you get and return literally thousands of objects a second ^^. Don't get fooled by the big O notation. Its just a measure how the complexity grows with the number of elements and makes absolutely no assumption about the actual complexity. For example dictionary or hashtable lookups and adding / removing values may have a complexity of O(1), however that only tells us that the complexity does not grow as the number of elements get larger. However that does not mean it's generally faster because the absolute complexity of a hashtable lookup is greater than linearly iterating through a small array. Hashtables split up the elements into buckets and slots which is bad for caching.

Sure you may be able to squeze out a bit of performance by throwing more memory at the problem or vice versa. The question is if it's worth it. If you don't have a performance or memory issue, it's usually not worth to worry about. Of course as long as you don't make any mistakes in your code, you don't need any safety checks and may get a performance boost. However if it's not a time critical thing it makes not much sense to take a risk that has almost no benefits but could cause huge sneaky bugs.

 

Thanks, that was clear!