Re: Benchmarking Dynamic Web XSLT

[Paul Tchistopolskii <paul at qub dot com>]

The numbers above are from my experiments with XT
with relatively small files ( web-pages are small, right ;-)

> How much does XT do on each request there? I'm assuming these fundamental
> steps:
> 
> 1. Parse source xml file into a tree structure

Not-that-much-time-consuming. Approx 5-10%. 
Caching looks not like a good idea. What should be cached? 

   DOM ? XT on top of DOM is much slower than XT on 
   top of OM ( internal XT structure, 'similiar' to DOM ).

   OM ? May help, but it will eat plenty of memory, because 
   that's not a plain text file, but some complex tree of different 
   obejcts.
   
Maybe caching is acceptable for some usecases,  but I think it is 
not worth the savings.

> 2. Determine template (from <?xml-stylesheet?> ??)

... well ... the name of the stylesheet could be provided as a parameter ...

> 3. Parse template xml file into a tree structure

Time consuming.  10-30%. But XT allows cloning the stylesheet and 
this works very well.

> 4. Perform XSLT transformations.

Strongly depends on the transformation. Most of transformations 
I have seen are trivial.  HTML-templatish  mode of XSLT 
(no  <xsl:apply-templates> ) could do the trick in most cases. If 
the idea is to produce tonns of sorted parts out of messy 
XML source file - that could be a plain killer.

> Basically you can skip 1, 3 and 4 given caching in the right places
> (unless of course one of either the source or template changes) but I
> don't know how far XT (and the other XSLT implementations) go on this.

XT is very good because it has (3) - realy helps.

Rgds.Paul.



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list