Object pool
(→Concerns) |
|||
| 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]] | ||
==Empty pools== | ==Empty pools== | ||
Revision as of 23:52, 19 October 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
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 object
- Return an exception to the client
- Block until an 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.
