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

[Liam R E Quin <liam holoweb net>]

[sorry if you get two of these, looks like it didn't make it out
yesterday]

On Thu, 2012-07-26 at 12:17 +0400, Дмитрий Грибов wrote: 
> 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.

Probably a good idea to do timings.

http://permalink.gmane.org/gmane.text.xml.xsl.general.mulberrytech/84488
mentions one timing that was done, but it's not with your data :-)

> [...]

> 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.
Yes, it's C. I don't know if you'll get a factor of two or a 5% speedup
by adding threading to libxslt - you obviously won't get a factor of N
(where there are N CPUs) without doing a lot of work.

Most of the work is likely
(1) parse the input and build a tree. Could maybe be parallel.
(2) process stylesheet. Mike Kay said he did get some speedups when he
introduced threading into Saxon here, as I recall, although not as much
from other areas. This part isn't likely to be easy, but is where the
most benefit might come.
(3) serialize result tree to XML and output it. Not easily threaded,
although if you generate multiple result documents in a single pass
there are some obvious benefits here.

> 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.

You're the first to have requested this that I've heard. Please feel
free to add a comment to the W3C Bugzilla explaining it in more detail.

Liam

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/