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

[Дмитрий Грибов <gribuseroccupied gmail com>]

Hi, folks!

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?