Just found out about some suboptimal serializer things in the current Cocoon CVS, and since I didn't find anything relevant in the mail archives, I thought I'd just come in and complain.
Pier was telling me something equivalent yesterday. Good timing!
There are actually 2 things:
* the current XML/HTML serializers are performing identity XSL transforms (with a real stylesheet!), instead of just serializing. This means that they require the building of a complete DTM-tree, effectively creating a buffer of all SAX-events entering the serializer. From the CVS logs, I see this has been introduced to work around a bug occuring in (of all things) the SourceWritingTransformer, though I did not find what exactly.
Holy shit! Didn't know that!
* by default, cocoon is configured with "incremental-processing" for XSL's set to true (this only applies when using xalan, not when using xsltc). Since Xalan manages this setting in a static variable, this property is shared for all XSL transformers in Cocoon. Since the serializer is also performing an XSL transform, it also applies to the serializer. Incremental processing is achieved by performing the transform on a separate thread. This means that a simple pipeline containing a (xalan) XSLT transform and a HTML serializer will already use 3 threads (the original request-dispatching thread, and an additional thread for each transform). (and the threads created by xalan are not pooled).
Oh dear. Talking about hotspots.
So what I would propose is:
* if the xsl-ing serializer workaround is only required by the SWT, lets make this behaviour configurable and make the default serializers not use it.
Totally +1. Even better, identify what's wrong with the SourceWritingTransformer and fix that without expensive workarounds!
* and possibly, lets set the incremental-processing to false per default. It has an advantage if and only if the processed XML is rather large, and the stylesheet is written is such a way that it can actually be performed incrementally (for most XSL's I've seen in practical use, this is not the case).
Agreed. +1
* finally (or better first of all), lets look if the serializer problems cannot be solved in xalan.
+10
Thanks for keeping us sane on this!
-- Stefano Mazzocchi <[EMAIL PROTECTED]> Pluralitas non est ponenda sine necessitate [William of Ockham] --------------------------------------------------------------------
