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
too.
best,
-Rob
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
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--