Re: [xslt] libxslt: xsl:include/import cache?

In message <>
          Elizabeth Mattijsen <> wrote:

> I've been looking for ways to reduce the memory usage of a web-server that
> will have a _lot_ of stylesheets, many of which will be referring to the
> same "subroutine" templates by using <xsl:include>.
> I understand that <xsl:include> is basically inserting the XML at the
> position where it is called.  So, each time a stylesheet is included with
> <xsl:include>, new memory is allocated and used (as far as I can see, anyway).
> I've been looking at the following lines in "libxslt/imports.c":
> ------------------------------------------------------------------
>      include = xsltLoadStyleDocument(style, URI);
>      if (include == NULL) {
>          xsltPrintErrorContext(NULL, style, cur);
>          xsltGenericError(xsltGenericErrorContext,
>              "xsl:include : unable to load %s\n", URI);
>          goto error;
>      }
>      oldDoc = style->doc;
>      style->doc = include->doc;
>      xsltParseStylesheetProcess(style, include->doc);
>      style->doc = oldDoc;
> --------------------------------------------------------------------
>  From this I conclude that for a given URI, memory is allocated and a
> pointer is returned by xsltLoadStyleDocument().  And then later that
> pointer is used to integrate into the "parent" stylesheet.
> Would it be _too_ simplistic to create a memory cache, keyed to URI, that
> would save the "include" pointer and return that if the stylesheet at that
> URI was already loaded before?  And this save a _lot_ of memory when
> multiple stylesheets use the same stylesheet through <xsl:include>?
> Or are there other issues that would prevent this from working?

Whilst I'm not clear on the internals of xslt's implementation, it might be
possible for the users callback function of the loader to do this. However,
there is little reason why the stylesheet requested could not be from a
remote resource (particularly if it's not found in the catalog). If it is
a remote resource [1], then there's no necessity for it to remain constant -
conside a URI such as

Consequently, it's probably not an issue for the libxslt implementation, but
for user code.

[1] local resources might also generate different data; take for example
    a local file that is coming from a unix pipe.

Gerph {djf0-.3w6e2w2.226,6q6w2q2,2.3,2m4}
... Eyes to the heavens, screaming at the sky;
    Trying to send you messages, but choking on goodbye.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]