Object pool pattern: Difference between revisions

Revision as of 02:03, 26 February 2021

Revision as of 02:15, 16 March 2021

Line 18:

The pooled object is obtained in predictable time when creation of the new objects (especially over network) may take variable time. 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 other 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|last1=Goetz|first1=Brian|date=2005-09-27|title=Java theory and practice: Urban performance legends, revisited|url=http://www.ibm.com/developerworks/java/library/j-jtp09275/index.html|url-status=dead|archive-url=https://web.archive.org/web/20120214195433/http://www.ibm.com/developerworks/java/library/j-jtp09275/index.html|archive-date=2012-02-14|access-date=2021-03-15|website=[[IBM]]|publisher=IBM developerWorks}}</ref> In case of simple memory pooling, the [[slab allocation]] memory management technique is more suited, as the only goal is to minimize the cost of memory allocation and deallocation by reducing fragmentation.

| url = http://www.ibm.com/

| title = Java theory and practice: Urban performance legends, revisited

| last1 = Goetz

| first1 = Brian

| date = 2005-09-27

| publisher = IBM developerWorks

| archive-url = http://www.ibm.com/developerworks/java/library/j-jtp09275/index.html

| archive-date = 2005-09-27

| access-date = 2012-08-28

}}</ref> In case of simple memory pooling, the [[slab allocation]] memory management technique is more suited, as the only goal is to minimize the cost of memory allocation and deallocation by reducing fragmentation.

== Implementation ==