Object pool pattern: Difference between revisions

Content deleted Content added
fixed "Removal of the direct memory management (putting the garbage collector instead) in the most cases actually make programs to run faster"
more grammar error corrections in the Critisism section
Line 24:
 
== Criticism ==
Some publications do not recommend using object pooling, especially for objects that only use memory and hold no external resources [http://www.ibm.com/developerworks/java/library/j-jtp11253/]. Opponents usually say that in modern languages with garbage collector thecollectors object allocation is relatively fast - while the operator "new" needs only 10 instructions, or about when thanthe classic "new" - "delete" pair found in pooling designs requires hundreds of them as it does more complex work. Also, the most of 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 the little cost. DifferentlyOn the other hand, keeping thea large number of "live" but unused objects increases the duration of the garbage collection [http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html?ca=dgr-jw22JavaUrbanLegends]]. In most cases, programs that use the garbage collectorcollection instead of directly managing memory actually run faster [http://www.cs.ubc.ca/local/reading/proceedings/spe91-95/spe/vol23/issue7/spe836.pdf].
 
== Examples ==