This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Benchmarking Dynamic Web XSLT
- To: xsl-list at mulberrytech dot com
- Subject: Re: Benchmarking Dynamic Web XSLT
- From: Paul Tchistopolskii <paul at qub dot com>
- Date: Tue, 18 Apr 2000 19:19:35 -0700
- Organization: The Qub Group
- References: <Pine.LNX.4.21.0004182112420.9288-100000@ted.sergeant.org>
- Reply-To: xsl-list at mulberrytech 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