Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <45B8B438.8010707@reverycodes.com>
Date: Thu, 25 Jan 2007 08:44:24 -0500
From: Vadim Gritsenko <vadim@reverycodes.com>
User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Object pooling considered harmful
References: <459AD722.6090304@nada.kth.se>
In-Reply-To: <459AD722.6090304@nada.kth.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.

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.

Vadim