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.
/Daniel
