Re: [xslt] Isn't it time to make libxslt multi-threaded?

[Дмитрий Грибов <grib gribuser ru>]

> Why not move to a more modern XSLT environment such as Saxon? Yes, it's
> in Java, but you can run it as a servlet or even with nailgun to avoid
> jvm startup costs, and then you get XSLT 2. With a little work - e.g.
> using explicit typing on variables - you might well get something that
> runs massively faster.
Saxon runs massively faster on Java? That's something really new for me. All
the benches I've seeing prove libxml and MSXML to be several times faster on
the overage task than anything else (particulary java-based engines). What
(and where) do I miss? We use java xslt for xsl:fo and it's just REALLY,
REALLY SLOW thing. It's good no real-time output there is required. If you
insist on that I'll make some benches. Our XSLT transformation is standalone
demon now, and it's relatively independent from the environment.

> Much as I might like libxslt, at W3C we're currently working on XSLT 3,
> and libxslt is still on XSLT 1. It's a lot of work to implement XSLT 2
> (or 3), of course, but it might be a better place to spend money.
We have quite a pragmatic task and we haven't those millions to invest in
XSLT3 implemenation. While dumb threading in libxslt seems to be really
cheap (as far as I could read it's C-code without knowing C) and will close
any our problem for a couple of years. xslt2 is nice, but the speed is
currently is the bottleneck. I will drop xslt 6.0 if it's not going to run 6
times faster.

ps. And as soon as here are some persons from Hi Heavens: add <xsl:cache
key="sdf{$sdfsdf}sdfsdf{@sdfsdf}"/> tag to some of your new versions. In the 
real
world the only thing XSLT is really missing now in compare to an average 
templating
engine - ability to use memcached. Really. web server is not abstract, it
must run as fast as possible and consume as few resources as possible. Data
model and all that is nice, but secondary to the basics.