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