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
smime.p7s
Description: S/MIME cryptographic signature
