[RT] Flyweight for Cocoon?

[Berin Loritsch <bl...@d-haven.org>]

One of the problems identified in Cocoon is the use of a great number of 
pooled components.  The complaint being that Cocoon is pooled to death. 
  Something that I ran into with a Swing based app that surprised me was 
the difference between reusing a JComponent object and changing its 
parameters vs creating a new one for each cell in a table.  The thing is 
that reusing that component resulted in a tremendous performance gain 
(20x).  Something to realize here is that the Flyweight pattern IS NOT 
POOLING.  You have a set of objects that have the most expensive part 
already done, and you reuse those objects reconfiguring as needed.

It got me to thinking if this could be done for Cocoon with similar 
results.  The part that might make it more difficult is the transformer. 
   Perhaps if we used the ThreadLocal object to keep the max number of 
transformers that would would need to use for any one thread and then 
configured them by reusing those instances we could cut down on the 
number of transformers/generators/serializers needed.

The per-thread approach would work as long as there is a guarantee of 
one thread per request--which seems to be valid for the current crop of 
servlet engines.

Re: [RT] Flyweight for Cocoon?

[Berin Loritsch <bl...@d-haven.org>]

Nicola Ken Barozzi wrote:

> 
> Well, usually we have *one* servlet handling *multiple* requests... 
> where's the new part :-?
> 

One servlet, many threads, with matching number of requests.

The thing is to leverage it to your advantage so that we don't create
more than we ever need to, and just have it ready to use--instead of
creating and destroying on demand.

Re: [RT] Flyweight for Cocoon?

[Nicola Ken Barozzi <ni...@apache.org>]

Pier Fumagalli wrote:

> On 25 May 2004, at 15:25, Berin Loritsch wrote:
> 
>> One of the problems identified in Cocoon is the use of a great number 
>> of pooled components.  The complaint being that Cocoon is pooled to 
>> death.  Something that I ran into with a Swing based app that 
>> surprised me was the difference between reusing a JComponent object 
>> and changing its parameters vs creating a new one for each cell in a 
>> table.  The thing is that reusing that component resulted in a 
>> tremendous performance gain (20x).  Something to realize here is that 
>> the Flyweight pattern IS NOT POOLING.  You have a set of objects that 
>> have the most expensive part already done, and you reuse those objects 
>> reconfiguring as needed.
>>
>> It got me to thinking if this could be done for Cocoon with similar 
>> results.  The part that might make it more difficult is the 
>> transformer.   Perhaps if we used the ThreadLocal object to keep the 
>> max number of transformers that would would need to use for any one 
>> thread and then configured them by reusing those instances we could 
>> cut down on the number of transformers/generators/serializers needed.
>>
>> The per-thread approach would work as long as there is a guarantee of 
>> one thread per request--which seems to be valid for the current crop 
>> of servlet engines.
> 
> The XSLT transformer already has quite a similar design pattern in the 
> JAXP implementation: the stylesheet is parsed and converted into a 
> thread-safe "Templates" object, which gets used by N threads at the same 
> time...
> 
> On a single thread, reusing the Templates object with SAXON I get up to 
> something like 30 transformations a second (the stylesheet is really big 
> and cumbersome, uses some external lookup tables), while if I keep 
> re-building the Templates from scratch I barely get up to 5/6 per second...

Well, usually we have *one* servlet handling *multiple* requests... 
where's the new part :-?

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------

Re: [RT] Flyweight for Cocoon?

[Pier Fumagalli <pi...@betaversion.org>]

On 25 May 2004, at 15:25, Berin Loritsch wrote:

> One of the problems identified in Cocoon is the use of a great number 
> of pooled components.  The complaint being that Cocoon is pooled to 
> death.  Something that I ran into with a Swing based app that 
> surprised me was the difference between reusing a JComponent object 
> and changing its parameters vs creating a new one for each cell in a 
> table.  The thing is that reusing that component resulted in a 
> tremendous performance gain (20x).  Something to realize here is that 
> the Flyweight pattern IS NOT POOLING.  You have a set of objects that 
> have the most expensive part already done, and you reuse those objects 
> reconfiguring as needed.
>
> It got me to thinking if this could be done for Cocoon with similar 
> results.  The part that might make it more difficult is the 
> transformer.   Perhaps if we used the ThreadLocal object to keep the 
> max number of transformers that would would need to use for any one 
> thread and then configured them by reusing those instances we could 
> cut down on the number of transformers/generators/serializers needed.
>
> The per-thread approach would work as long as there is a guarantee of 
> one thread per request--which seems to be valid for the current crop 
> of servlet engines.

The XSLT transformer already has quite a similar design pattern in the 
JAXP implementation: the stylesheet is parsed and converted into a 
thread-safe "Templates" object, which gets used by N threads at the 
same time...

On a single thread, reusing the Templates object with SAXON I get up to 
something like 30 transformations a second (the stylesheet is really 
big and cumbersome, uses some external lookup tables), while if I keep 
re-building the Templates from scratch I barely get up to 5/6 per 
second...

	Pier