90: Design Patterns: Object Pool.

What is the object pool design pattern? The object pool behavioral pattern allows you to reuse objects instead of destroying and creating them again. This can help when objects are big and expensive to create or when you have a lot of them. Over time, this pattern also keeps your computer memory from becoming fragmented and running out of memory. This design pattern helps solve two big problems that applications encounter with managing memory especially over a long period of time. Sometimes objects just take a long time or are otherwise expensive to create. Even if your objects are small and quick, you might sometimes need a lot of them. As you use and then free memory, a normal memory manager will build up sections of memory that while available are too small to use for large objects because there are other objects sitting in the middle or between free sections. With this pattern, you allocate a block of memory when your application starts and use that memory to allocate objects that you don’t delete. Instead of deleting them, you mark them with a flag when they are not being used by some other code and are available. Then you manage this collection of objects yourself. This becomes your pool of objects. Anytime some code needs one of these objects, instead of allocating a new block of memory for that one object, do this instead to use the object pool: Find an available object that already exists in the pool, Mark the object as no longer available, Initialize it as if it was just created, And give it to the calling code. When the other code is done with the object, instead of deleting it, it gets returned back to the pool. This just means that the object becomes available again. Listen to the full audio episode or you can also read the transcript below. If you’d like to read the book that describes this pattern along with diagrams and sample code, then you can find Game Programming Patterns at the Resources page. You can find all my favorite books and resources at this page to help you create better software designs. Transcript The basic description says that this pattern improves both performance and memory use by reusing objects from a collection instead of creating new instances and then deleting them when done. We definitely live in a more disposable world now than what life was like 50 or a hundred years ago. We have disposable food wrappers and cups, furniture that’s made from cheap particle board instead of solid wood, even disposable cameras. While sometimes convenient, this can be expensive and cause problems. In programming terms, it all comes down to bits in the computer memory. So at least we’re not throwing those away too. It is still expensive because when you create a new object, some code needs to run to find room for the object, record the memory to be in use, and then run the constructor. If the constructor also takes a long time to do its job, then you can see where this can add up. But what kinds of problems can this cause? For that, let me describe a little about how the main memory in your computer works. Each running application is given a certain amount of memory and the application manages the memory by creating a heap structure to track available and used memory. The memory manager doesn’t know anything about the specific usage needs of your application. It just tries to find a spot in memory big enough to fit some requested memory and when you’re done, it’ll make that memory available again. Let’s go to a kitchen example again. There’s no cakes this time. We’re going to talk about the cupboards and drawers. Imagine all your kitchen cabinets are empty and when you want to get a plate, or a cup, or a spoon, then one appears on demand. This is kinda cool. But it comes at a cost. While you’re using this newly created utensil, it continues to claim space in the drawer or shelf where it was first created. At first this is no problem. Y