Besides code-reuse and output consistency, one of the things driving this
refactoring is indeed performance. Xalan interpretive writes out to
ResultTreeHandler first and resolves namespaces, collects attributes
(needed because of xsl:attribute), sets up start/endPrefixMapping, etc. A
lot of this work doesn't need to be done in the case of stream
serialization. XSLTC, on the other hand, writes directly to the
TransletOutputHandler interface, and then delegates to the true SAX
interfaces when it is interfacing to a ContentHandler, etc. I think
XSLTC probably got it right. Brian didn't mention this in his note, or it
didn't come across as such, but the idea is for Xalan to write directly to
the new XalanOutputHandler, thus skipping the layer of indirection for
streams. As Brian noted to me offline, we don't really know how much of a
perf improvement this will be for Xalan interpretive until we measure it,
but, in theory, it could be a big help.
Also, having a single code base for the serializers in XSLTC and Xalan
interpretive will allow us to better focus on general perf improvements in
the serializers. I suspect the "cleaner" part of what he's proposing will
also help us in measuring performance... as you know, the overhead of
ResultTreeHandler has always been a complicating factor in our profiling.
-scott
Joseph Kesselman <[EMAIL PROTECTED]> wrote on 12/12/2002 01:15:39 PM:
> Just one quick point: Serialization performance is critical to the
> perfomance of Xalan overall. Be careful when working on this code;
cleaner
> and slower is not necessarily a good trade-off!
>
> ______________________________________
> Joe Kesselman / IBM Research
>
