cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Object pooling considered harmful
Date Thu, 25 Jan 2007 21:53:50 GMT
Vadim Gritsenko skrev:
> Daniel Fagerstrom wrote:
>> What is this object pooling about? Once, long time ago, Java was 
>> really slow in creating and destroying objects ...
>> Now with modern JVMs (1.2 and later), things has changed dramatically. 
>> Creation and destruction of objects is amazingly fast. A "new 
>> Object()" is about 10 machine instructions ...
> In Cocoon pooling was mostly for (relatively heavy) sitemap components. 
> Problem is not memory allocation (new FooGenerator()) - this is the 
> fastest part - problem lies in component lifecycle. If you combine costs 
> of instance initialization, contextualization, configuration, setting 
> service manager for a component, you'd arrive to much greater number.

Sure, but these life cycles steps is much cheaper for a Spring managed 
bean that uses prototype scope than for an ECM managed single threaded 
component. For a Spring managed bean in prototype scope the 
configuration is only needed to be parsed once at container setup time 
while the configuration needs to be traversed at every component 
creation for Avalon components that are single threaded. Likewise for 
service lookup and contextualization.

Of course some components might still be so heavy to create that pooling 
is worthwhile. But compiler development together with that Spring 
framework works differently than ECM, changes the situation so that many 
components that many components that were worthwhile to manage with a 
pool once, is  much cheaper to recreate today.

> Granted, some of the sitemap components are trivial to create (e.g: 
> StripNamespacesTransformer), but some others might take ages. There is 
> no "one size fits all" solution, I'm afraid.
> If pooling is dropped completely, heavier sitemap components would have 
> to be split up into "back end" components doing heavy lifting and "front 
> end" components with simplified lifecycle. I18nTransformer could be 
> thought of as an example of this pattern. It won't help though 
> "mid-weight" components, whose fat is mostly located in the configure() 
> method.

There is no reason to drop pooling for Avalon components as we have an 
implementation of pooling in the Avalon-Spring bridge.

For the components that we convert to Spring managed POJOs, it is in 
general better to try to rewrite them as you describe above as pooling 
doesn't fit well together with the way the Spring framework works.


View raw message