"Don't Search For Instructions Until..." statement?

Discussion in 'XML' started by VK, May 28, 2006.

  1. VK

    VK Guest

    Let's say I have a rather big HTML template like

    <?xml version="1.0" encoding="ISO-8859-1"?>
    ....
    <snip>
    ....
    <xsl:template match="/">
    <html>
    <!-- ...
    A lot of HTML but no XSL so far
    .... -->
    <xsl:for-each select="repository/item">
    <!--
    Here finally XSL comes into play
    -->
    </xsl:for-each>
    ....
    </html>
    </xsl:template>
    </xsl:transform>

    If I understand properly, XSL will still study each line after
    <xsl:template match="/"> for XSL command wasting its time. Is there a
    way to start output (thus use
    <xsl:template match="/">) but postpone XSL parsing until some
    predefined sequence? Namely I'm thinking of some kind of Perl
    equivalent of single-quote print block like
    print <<'EOT'
    ....
    EOT
    VK, May 28, 2006
    #1
    1. Advertising

  2. VK wrote:
    > If I understand properly, XSL will still study each line after
    > <xsl:template match="/"> for XSL command wasting its time.


    I suspect that isn't going to take a significant amount of time, but if
    you insist on trying to avoid it -- move some of the literal content out
    of the template into a stylesheet variable, and just insert its value.

    Alternatively, switch to a compiled stylesheet system such as Xalan's
    XSLTC support, which will probably optimize this automagically without
    your having to do anything to the stylesheet.
    Joe Kesselman, May 30, 2006
    #2
    1. Advertising

  3. VK

    Andy Dingley Guest

    VK wrote:

    > If I understand properly, XSL will still study each line after
    > <xsl:template match="/"> for XSL command wasting its time.


    Yes, it's called "parsing".

    In practice, parsing is typically the slowest part of building
    server-side web output when loading a new stylesheet each time. So look
    at an XSLT transform engine that allows you to cache this after loading
    and re-use the same stylesheet next time. It's a useful saving.
    Andy Dingley, May 30, 2006
    #3
  4. Andy Dingley <> wrote:
    > at an XSLT transform engine that allows you to cache this after loading
    > and re-use the same stylesheet next time. It's a useful saving.


    Note that the TrAX APIs support this -- you can load a stylesheet once
    (which is when stylesheet parsing generally occurs) and then invoke it
    multiple times.
    Joe Kesselman, May 30, 2006
    #4
  5. VK

    VK Guest

    Joe Kesselman wrote:
    > Andy Dingley <> wrote:
    > > at an XSLT transform engine that allows you to cache this after loading
    > > and re-use the same stylesheet next time. It's a useful saving.

    >
    > Note that the TrAX APIs support this -- you can load a stylesheet once
    > (which is when stylesheet parsing generally occurs) and then invoke it
    > multiple times.


    Thanks to both of you.

    Does enclosing non-XSL part of template into <xsl:text>...</xsl:text>
    have an effect on parsing (speed)? Would be glad to be pointed to some
    specs/test results.
    VK, May 31, 2006
    #5
  6. VK wrote:
    > Does enclosing non-XSL part of template into <xsl:text>...</xsl:text>
    > have an effect on parsing (speed)?


    I wouldn't expect xsl:text to make much difference in stylesheet
    parse-and-interpret-or-compile speed.

    Note that you can't use xsl:text to escape literal result elements; as
    its name implies it's intended to give more explicit control over the
    boundaries of character content.

    I strongly suspect you're micro-optimizing the wrong part of your
    problem. Have you run a performance analysis to find out where your
    system is actually spending its time? As with any programming language,
    rewriting a stylesheet can sometimes tremendously improve its performance.
    Joe Kesselman, May 31, 2006
    #6
  7. VK

    VK Guest

    Joe Kesselman wrote:
    > I wouldn't expect xsl:text to make much difference in stylesheet
    > parse-and-interpret-or-compile speed.


    ACK - but I'll still check with timers.

    > Note that you can't use xsl:text to escape literal result elements; as
    > its name implies it's intended to give more explicit control over the
    > boundaries of character content.


    ACK

    > I strongly suspect you're micro-optimizing the wrong part of your
    > problem.


    Actually I don't have any performance problems right at this moment.
    I'm just thinking of some common technics (of they exists) for
    optimisation of non-XSL part of templates.
    VK, May 31, 2006
    #7
  8. VK wrote:
    > Actually I don't have any performance problems right at this moment.
    > I'm just thinking of some common technics (of they exists) for
    > optimisation of non-XSL part of templates.


    The best ways to optimize those are to do so inside the XSLT processor
    (a) compile the stylesheet, and (b) while you're at it, prepare blocks
    of literal output so they can be dumped out relatively quickly.

    --
    () ASCII Ribbon Campaign | Joe Kesselman
    /\ Stamp out HTML e-mail! | System architexture and kinetic poetry
    Joe Kesselman, Jun 1, 2006
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    3
    Views:
    802
  2. Jay McGavren
    Replies:
    11
    Views:
    1,130
    Alan Krueger
    Jan 16, 2006
  3. tedsuzman
    Replies:
    2
    Views:
    7,079
    Michel Claveau, résurectionné d'outre-bombe inform
    Jul 21, 2004
  4. Ted
    Replies:
    1
    Views:
    461
    Duncan Booth
    Jul 22, 2004
  5. Replies:
    21
    Views:
    1,053
    Giannis Papadopoulos
    Aug 2, 2005
Loading...

Share This Page