RE: more on XSLT processor performance

[Matt Sergeant <matt at sergeant dot org>]

On Tue, 1 Aug 2000, Sebastian Rahtz wrote:

> Matthew Bentley writes:
>  > >For my type of work, in my computer setup, Saxon wins pretty
>  > >easily. Others will have different criteria to choose from what is
>  > >really a very rich field of contenders.
>  > 
>  > I agree. Saxon, at the current point in time, seems to be the winner.
>  > However, I'd like to see more compiled XSLT processors than Java ones.
>  > 5.5 hours to process a 69 MB file is not practical -
> 
> what does that have to do with compiled?  seriously. when the Java one
> gets into memory, do you really see a huge difference in the kind of
> work an XSLT processor does? ie string processing and walking tree
> structures in memory.

Depends what you're processing. If its mainly western characters, then a
Java processor is going to probably use nearly twice as much memory as a C
based one (2byte characters vs utf-8). And if you're hitting swap space
that becomes a big deal. (and yes, I'm well aware that the utf-8 one will
consume more memory in certain cases).

Also, without hotspot, the C compiler is much more likely to produce
faster code at this point in time. Just picture traversing an array of
child nodes. In Java there is a bounds check on each access (unless I'm
mistaken about the implementation, in which case I appologise to all the
Java crowd out there). In C there is no such check (unless hand coded).
There are obvious pros and cons to this.

-- 
<Matt/>

Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list