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: Robert Koberg <rob@xxxxxxxxxx>
Date: Mon, 17 Sep 2007 07:39:50 -0400
Even if you could serialize the processor object on the client, you will
probably want to hit the server at least once to see if the XSL file is
modified. If you have xsl:import/include's, you will need to check those


On Mon, 2007-09-17 at 13:13 +0200, Abel Braaksma wrote:
> 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