Content deleted Content added
m use {{for}} |
m WP:CHECKWIKI error 61 fix, References after punctuation per WP:REFPUNC and WP:PAIC using AWB (8459) |
||
Line 6:
Object pooling can offer a significant performance boost in situations where the cost of initializing a class instance is high, the rate of instantiation of a class is high, and the number of instances in use at any one time is low. The pooled object is obtained in predictable time when creation of the new objects (especially over network) may take variable time.
However these benefits are mostly true for objects that are expensive with respect to time, such as database connections, socket connections, threads and large graphic objects like fonts or bitmaps. In certain situations, simple object pooling (that hold no external resources, but only occupy memory) may not be efficient and could decrease performance.<ref name="urban">{{cite web
| url = http://www.ibm.com/
| title = Java theory and practice: Urban performance legends, revisited
Line 18:
| quote =
| accessdate = 2012-08-28
}}</ref>
== Handling of empty pools ==
Line 51:
| quote =
| accessdate = 2012-08-28
}}</ref> Opponents usually say that object allocation is relatively fast in modern languages with [[Garbage collection (computer science)|garbage collectors]]; while the operator <code>new</code> needs only ten instructions, the classic <code>new</code> - <code>delete</code> pair found in pooling designs requires hundreds of them as it does more complex work. Also, most garbage collectors scan "live" object references, and not the memory that these objects use for their content. This means that any number of "dead" objects without references can be discarded with little cost. In contrast, keeping a large number of "live" but unused objects increases the duration of garbage collection.<ref name="urban" />
== Examples ==
In the .NET [[Base Class Library]] there are a few objects that implement this pattern. <code>System.Threading.ThreadPool</code> is configured to have a predefined number of threads to allocate. When the threads are returned, they are available for another computation. Thus, one can use threads without paying the cost of creation and disposal of threads.
Java supports thread pooling via <code>java.util.concurrent.ExecutorService</code> and other related classes. The executor service has a certain number of "basic" threads that are never discarded. If all threads are busy, the service allocates the allowed number of extra threads that are later discarded if not used for the certain expiration time. If no more threads are allowed, the tasks can be placed in the queue. Finally, if this queue may get too long, it can be configured to suspend the requesting thread.
== See also ==▼
* [[Connection pool]]▼
* [[Free list]]▼
==References==
Line 71 ⟶ 75:
| url = http://www.kircher-schwanninger.de/michael/publications/Pooling.pdf
| accessdate = 2007-06-09 }}
▲== See also ==
▲* [[Connection pool]]
▲* [[Free list]]
==External links==
| |||