On Sun, 6 Oct 2002, Sylvain Wallez wrote: > Stefano Mazzocchi wrote: > > > Hello people, > > > > I'm currently at Giacomo's place and we spent a rainy afternoon > > profiling the latest Cocoon to see if there is something we could > > fix/improve/blah-blah. > > > > WARNING: this is *by no means* a scientific report. But we have tried > > to be as informative as possible for developers. > > > > We were running Tomcat 4.1.10 + Cocoon HEAD on Sun JDK 1.4.1-b21 on > > linux, instrumented with Borland OptimizeIt 4.2. > > > > Here is what we discovered: > > > > 1) Regarding memory leaks, Cocoon seems absolutely clean (for cocoon, > > we mean org.apache.cocoon.* classes). Avalon seems to be clean as > > well. Good job everyone. > > > > 2) we noticed an incredible use of > > org.apache.avalon.excalibur.collections.BucketMap$Node. It is *by far* > > the most used class in the heap. More than Strings, byte[], char[] and > > int[]. Some 140000 instances of that class. > > > > The number of bucketmap nodes grows linearly with the amount of > > different pages accessed (as they are fed into the cache), but even a > > cached resource creates some 44 new nodes, which are later garbage > > collected. > > > > 44 is nothing compared to 140000, but still something to investigate. > > > > So, discovery #1: > > > > BucketMaps are used *a lot*. Be aware of this. > > > IFAIK, bucketmaps are used as soon as a component is looked up, and > getting a page from cache shouldn't reduce much the number of lookups > since the pipeline has to be built to get the cache key and validity. > > <thinking-loudly> > What could save some lookups is to have more ThreadSafe components, > including pipeline components. For example, a generator could > theroretically be threadsafe (it has mainly one generate() method), but > the fact that setup() and generate() are separated currently prevents this.
IIRC this is what Berin proposed long ago but never made it into the code. I'm not sure we can unify those method without breaking cantracts. > Also we have to consider that component lookup is more costly than > instanciating a small object. Knowing this, some transformers and > serializers can be thought of as factories of some lightweight content > handlers that do the actual job. These transformers and serializers > could then also be made ThreadSafe and thus avoid per-request lookup. Ok. > This would require some new interfaces, which should coexist with the > old ones to ensure backwards compatibility. probably. Giacomo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
