xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mosiewicz <m...@interdata.com.pl>
Subject Re: SAX
Date Sat, 13 May 2000 20:27:03 GMT
Scott Boag/CAM/Lotus wrote:
> [...]
> Interesting theory, but it's hard for me to see what kind of "structure
> level caching" could be done, even if the serializer had Schema information
> about the result tree.  Could you give an example?  I'm always very
> interested to consider performance gains that could be made in the
> Serializer.

The problem with structure level caching is that there is no ready to
use technology provided by w3c. 

When I developed mainly using JSPs, I sometimes noticed hotspots in the
code. So, I built a 'cache' taglib that would wrap some code inside.
Basically this taglib saves the output of the code contained inside, and
if it is satisfied with certain conditions it is able to prevent
executing the contained code. So while I was able to create fully
dynamic code for highly personalized content, I could also make a good
use of pregenerated output. 

The same technique would be accomplished by using xml caching mechanism,
but here it would be used much cleaner, and give more gain. For example,
in your xsl you could use something like (note that it's a simplified

<xsl:template match="cpu-expensive-content">
	<xcache:cacheable expires="5 m" ...>

So, assuming that there is a producer that generates this
'costly-content' tag, it could look like this:

if( contentHandler.startTag("cpu-expensive-content") != SKIP_TAG ) {
  here it generates some subelements which is cpu-expensive

So, once this startTag event gets to the stylesheet, it triggers
<xcache:cacheable> event. When this event gets to the serializer, it can
check if this content is cached in serialized form, in case if xcache
extension confirms it, it can return SKIP_TAG, which is propagated back,
so it finally get's to the content producer. Then you know what happens
- there is no event generated for subelements, this costly fragment in
the producer is not executed, and the serializer benefits of sending a
raw buffer of data to the browser.

I specifcally added this xcache event in the transformer to show, that
this xcache extension would be used in any place in the transformation
path (potentially it could be also directly used by the content
producer), and it would result in optimising the _whole_ path, so both
serializer and producer can benefit of reduced execution time. 

-- Mike

View raw message