> From: Sylvain Wallez [mailto:[EMAIL PROTECTED] > > Found a very interesting read at > http://www-106.ibm.com/developerworks/library/j-jtp01274.html? > ca=drs-j0504 > > This articles explains the memory allocation and collection > strategies of modern JVM and show that object recycling and > pooling can cause more harm than good.
Yes, but he links to a presentation from JavaONE, that summarizes pooling with: http://servlet.java.sun.com/javaone/resources/content/sf2003/conf/sessio ns/pdfs/1522.pdf + Loses for light-weight objects + A wash for mid-weight objects (Hashtables) + A win for big objects. Basically - if your object is significantly bigger than a Hashtable, you should pool it. What it boils down to is this: Is the time it takes to bring the object out of the pool (with the associated synchronization costs) longer than it takes to re-create the object? For Cocoon, I'm not sure that's the case. I think most objects in Cocoon are "big" by the definition given above. /LS
