Re: XSL performance problem

["Oren Ben-Kiki" <oren@xxxxxxxxxxxxx>]

Nantapon Chaimunkong <b38npc@xxxxxxxx> wrote:
>Can you share with us what optimization is expected in the future release
>of xsl processor? Some members of the list mention tenfold improvement. I
>think 3x(of December draft's xt - I haven't timed the new xt.) improvement
>is hardly possible as I thinks xt is at least partially-optimized.


That was me - and I said I wouldn't be surprised to see such a speedup, not
that I have a detailed plan of how to achieve it. In my experience, moving
away from the safe and clean world of immutable objects to reusable mutable
objects helps a lot. I haven't gone into the code of XT and XP in a serious
manner so I don't know how applicable that is. And, there are also
algorithmic improvements - optimizing data structures for certain types of
queries, etc.

We should also keep in mind that interpreting XSL is only one option; as
SAXON has demonstrated, there's the option of compiling it into some
programming language (SAXON provides compilation to Java). A whole new world
of optimizations becomes possible when dealing with a fixed XSLT stylesheet.

>I've also made an xsl processor and tried to optimize it a lot. It
>still does not go near xt.


Well, you are competing against the best :-)

>I've also found that the JVM ,suiting for (some) xsl processors, is
>microsoft jview. The new hotspot is very disappointing.


I had someone try the hotspot pre-release version, with similar results. Now
they have made a formal release so I'll look into it more seriously. But
even if hotspot fails to deliver the goods, other JVMs offer great
performance - IBM's for example.

Share & Enjoy,

    Oren Ben-Kiki


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