This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
RE: hardware xml / xslt
- From: "Robert Koberg" <rob at koberg dot com>
- To: <xsl-list at lists dot mulberrytech dot com>
- Date: Tue, 24 Sep 2002 10:30:50 -0700
- Subject: RE: [xsl] hardware xml / xslt
- Reply-to: xsl-list at lists dot mulberrytech dot com
Hi,
> -----Original Message-----
> From: owner-xsl-list@lists.mulberrytech.com
> [mailto:owner-xsl-list@lists.mulberrytech.com]On Behalf Of Michael Kay
> Sent: Tuesday, September 24, 2002 9:49 AM
>
> I think that memory is probably a more critical measure than speed. For
> a few sites, it's the number-of-small-transforms-per-second that's
> critical, but most of the problems I get to see nowadays are large
> document transformations, and they tend to be memory limited.
Another memory related issue: It would be a great thing if the processors could
separate out and cache just once xsl:includes/imports and some link them into a
Templates object.
Let's say I have 100 sites on a machine, each has there own look and feel by
having unique primary/entry XSLTs (say about 10 per site). Each of these
primaries includes a universally common set of XSLs.
With the way the processors currently handle things there will be 1000 large
Templates objects. But if I could cache the big, common include and stick that
in each tiny Templates object I would reduce memory usage.
I know I asked about this a year or so ago and it was not possible then (Saxon
and Xalan). Is this possible today?
-Rob
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list