Re: [xsl] Client-side compiled XSLT/DOM Persistence (was Re: [xsl] [XSL] XSL Browser Integration)

Subject: Re: [xsl] Client-side compiled XSLT/DOM Persistence (was Re: [xsl] [XSL] XSL Browser Integration)
From: Abel Braaksma <abel.online@xxxxxxxxx>
Date: Mon, 17 Sep 2007 13:13:06 +0200
Robert Koberg wrote:
I also wonder how much would be gained by reading back in a serialized
processor object (if it were possible) versus just rebuilding a DOM
(free threaded in MS's case) and creating the object. Probably
something, but maybe in the 100s of ms range???


It's been a while that I tested this performance. There's a huge gain when you want to recompile the same stylesheet several times for the same page. Especially with RIA it comes in very handy if the compiled object is persisted. But that is what you (Robert) and I and probably many others have already successfully accomplished automatically (in my case with a simple hash lookup table based on the URI of the XSLT that is to be loaded).

But when it comes to performance there's a large difference between whether the browser has already needed the XSLT engine previously (whether on the same page or others) or not. When it has to initialize the XSLT engine, my best measurements where that it took about 120ms to 400ms, depending on browser and situation. After that, compiling a medium sized (but what is medium?) stylesheet takes on average 30ms in my experience.

Also there, the browser seems to do some caching, as I found out that it is quite some slower to recompile a new stylesheet or an old one. Also, there's some difference between a stylesheet created from scratch by a DOM in memory and one that is created from a URL or XHR-returned object. The DOM memory one is lightning fast, the URL seems to be cached using normal caching (difference in performance if you set the server to no cache response header for the XSLT) and the XHR again depends on a GET or a POST: the latter being slower, it is not cached, it seems. But both being slower than direct URL retrieval (on IE doubly so because you have to rebuild the XML as freethreaded).

I don't remember the timings I had in the past (and in particular, I like to do timing estimates only once, to later find out that I took the wrong approach anyway), but it is clear that there's a lot to gain when you design your client side stylesheets to be cached with both the browser side (normal file cache) and code: a hash table or anything else that suffices your needs.

Cheers,
-- Abel Braaksma

Current Thread