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

[Stefan Behnel <stefan_ml behnel de>]

Дмитрий Грибов, 25.07.2012 23:59:
> It is not about bugs or faq and it's going to be a long story. Yet I
> believe this really worth it.
> 
> We are using xslt for web-serving for, I believe, 10+ years. For today we
> have quite a dedicated and robust templates trees that processes a huge
> and dedicated xml with libxslt. All is nice and fine, but average
> transformation time is 0.15s. And it's turning from sad to unacceptable.
> Processors nowadays have many cores, but brute-force speed does not look
> really promising.
> 
> As I was searching for a way to fix the problem I considered some options:
> 1. Simplify layout and templates. Unnacceptable for many reasons.
> 
> 2. Abandon xslt. As I believe, the speed issue is fixable, in any other
> way xslt is a complete winner - so not an option.
> 
> 3. Partial transformation + application-level assembling and caching of
> output fragments. This is good, but still not good enough.
> 
> 4. Multithreaded async partial transformation + application-level caching
> + application level assembly. That sounds promising (and looks fearsome).
> 
> So I stuck to option 3.
> And then...
> 
> As long as I was digging the idea, I realized that I am going to spend
> tonns of time to emulate from outside the xslt-engine quite a simple and
> native for xslt itself concept: asynchronous transformation. The threading
> magic must reside within libxslt! That becomes obvious quite soon, as you
> start thinking. And that must be quite easy to do now, as libxml is
> thread-safe already.
> 
> Isn’t it a time to do some threading?

Just to get this discussion back on track, where would you apply threading
in libxslt? An answer to that, as well as an implementation, may not be as
trivial as you seem to think. Also, it would at least require some kind of
scheduling mechanism in order to distribute jobs (such as matching nodes or
called templates) over the threads.

One of the obvious approaches would be a map-reduce pattern. That would fit
very well with the functional and hierarchical nature of XSLT and XML in
general.

Stefan