When to go for object pooling?

Question

When to go for object pooling using C#? Any good ex...

What are the pro's and con's of maintaining a pool of frequently used objects and grab one from the pool instead of creating a new one?

Answer 1

I would add memory fragmentation to the list. That can occur when using objects that encapsulate native resources which after they are allocated can not be moved by the Garbage Collector and could potentially fragment the heap.

One real-life example is when you create and destroy lots of sockets. The buffers they use to read/write data have to be pinned in order to be transferred to the native WinSock API which means that when garbage collection occurs, even though some of the memory is reclaimed for the sockets that where destroyed - it could leave the memory in a fragmented state since the GC can't compact the heap after collection. Thus the read/write buffers are prime candidates for pooling. Also, if you're using SocketEventArgs objects, those would also be good candidates.

Here's a good article that talks about the garbage collection process, memory compacting and why object pooling helps.

Answer 2

There are only two types of resources I can think of that are commonly pooled: Threads and Connections (ie to a database).

Both of these have one overarching concern: Scarcity.

• If you create too many threads, context-switching will waste away all of your CPU time.
• If you create too many network connections, the overhead of maintaining those connections becomes more work than whatever the connections are supposed to do.
• Also, for a database, connection count may be limited for licensing reasons.

So the main reason you'd want to create a resource pool is if you can only afford to have a limited number of them at any one time.

Answer 3

1. When object creation is expensive
2. When you potentially can experience memory pressure - way too many objects (for instance - flyweight pattern)

Answer 4

For games GC may introduce an unwanted delay in some situations. If this is the case, reusing objects may be a good idea. There's are some useful considerations on the topic in this thread .

Answer 5

There is an excellent MSDN magazine article called Rediscover the Lost Art of Memory Optimization in Your Managed Code by Erik Brown http://msdn.microsoft.com/en-us/magazine/cc163856.aspx . It includes a general purpose object pool with a test program. This object pool does support minimum and maximum sizes. I can't find any references to people using this in production. Has anyone done so? Also, having dealt with memory fragmentation in an ASP.NET application I can attest to the value in Miky Dinescu's answer. Also, elaborating slightly on Vitaly's answer, consider the case of large objects (ie > 85K) which are expensive to create. Large objects only participate in Gen 2 garbage collection. This means that they won't be collected as quickly as objects that fully participate in garbage collection in Gen 0 and Gen 1. This article Large Object Heap Uncovered by Maoni Stephens at http://msdn.microsoft.com/en-us/magazine/cc534993.aspx explains the large object heap in detail.