Object pool
(New page: The object pool design pattern can be used to aid performance when objects are expensive to create, by using caching. An object pool, usually implemented as a Singleton class, manages ...) |
m (Reverted edits by Ebybymic (Talk); changed back to last version by James Ashford) |
||
| (8 intermediate revisions by 5 users not shown) | |||
| Line 1: | Line 1: | ||
| − | The object pool design pattern can be used to aid performance when objects are expensive to create, by using caching. An object pool, usually implemented as a [[Singleton]] class, manages a pool of objects that have already been instantiated. Clients can request objects from the pool instead of creating them and return them once they are done with them. | + | The object pool design pattern can be used to aid performance when objects are expensive to create, by using caching. An object pool, usually implemented as a [[Singleton]] class, manages a pool of objects that have already been instantiated. Clients can request objects from the pool instead of creating them and return them once they are done with them. |
An object pool should be considered when: | An object pool should be considered when: | ||
| Line 7: | Line 7: | ||
Care should be taking not to use [[Premature optimization]] when considering this pattern, and also to avoid creating an [[Object cesspool]]. | Care should be taking not to use [[Premature optimization]] when considering this pattern, and also to avoid creating an [[Object cesspool]]. | ||
| + | |||
| + | ==Structure== | ||
| + | [[Image: Object_pool.PNG]] | ||
| + | |||
| + | '''Figure - Generic structure of the Object Pool''' | ||
| + | |||
| + | ==Intent== | ||
| + | The Object Pool pattern manages the reuse of objects when there is a limit on the number of objects to be created, or it is expensive to create. | ||
| + | |||
| + | ==Solution== | ||
| + | The '''Client''' calls ReusablePool's ''aquireReusable'' method when it wants a '''Reusable''' object. | ||
| + | |||
| + | ==Empty pools== | ||
| + | When all available objects are already allocated and a request is made one of several strategies can be utilised: | ||
| + | *Increase the pool size and create another '''Reusable''' object | ||
| + | *Return an exception to the '''Client''' | ||
| + | *Block until a '''Reusable''' object is returned to the pool | ||
| + | |||
| + | ==Concerns== | ||
| + | Some concerns have be expressed about programs that implement very large object pools in languages with dynamic garbage collection. Object pools can also increase the average memory footprint of an application. The theory is that the large number of objects in the pool slow garbage collection routines even when the objects are not in use thus negatively impacting performance. | ||
| + | |||
| + | To address this issue, limit the number of objects that can be created. | ||
==Related patterns== | ==Related patterns== | ||
| Line 14: | Line 36: | ||
==See Also== | ==See Also== | ||
*[[Object cesspool]] | *[[Object cesspool]] | ||
| + | *[[Identity map pattern]] | ||
[[Category:Design Patterns]] | [[Category:Design Patterns]] | ||
Latest revision as of 03:22, 25 November 2010
The object pool design pattern can be used to aid performance when objects are expensive to create, by using caching. An object pool, usually implemented as a Singleton class, manages a pool of objects that have already been instantiated. Clients can request objects from the pool instead of creating them and return them once they are done with them.
An object pool should be considered when:
- There is a high cost of creating new objects of a particular type
- The rate of instantiation is high
- The number of instantiations in use at a particular time is low
Care should be taking not to use Premature optimization when considering this pattern, and also to avoid creating an Object cesspool.
Contents |
Structure
Figure - Generic structure of the Object Pool
Intent
The Object Pool pattern manages the reuse of objects when there is a limit on the number of objects to be created, or it is expensive to create.
Solution
The Client calls ReusablePool's aquireReusable method when it wants a Reusable object.
Empty pools
When all available objects are already allocated and a request is made one of several strategies can be utilised:
- Increase the pool size and create another Reusable object
- Return an exception to the Client
- Block until a Reusable object is returned to the pool
Concerns
Some concerns have be expressed about programs that implement very large object pools in languages with dynamic garbage collection. Object pools can also increase the average memory footprint of an application. The theory is that the large number of objects in the pool slow garbage collection routines even when the objects are not in use thus negatively impacting performance.
To address this issue, limit the number of objects that can be created.
