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

Stefan Behnel, 27.07.2012 22:58:
> Liam R E Quin, 27.07.2012 19:09:
>> [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.
>> mentions one timing that was done, but it's not with your data :-)
> Interesting. Taking a quick look over the stylesheet, it's actually fairly
> likely that it's due to the XPath performance bug that is currently being
> worked on in libxml2. Basically, node set sorting is horribly slow in many
> cases, which specifically hits deeply stacked XPath expressions. Would be
> worth applying the proposed patch and rerunning the timings. It can easily
> give you a couple of factors in performance.

... but not in this case. I tried the patch and it only gives me some 10%
improvement. Most of the time is spent in the XPath evaluation, though.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]