Re: speed issues with XSL:FO tables.

> From: Arvind Parthasarathy <arvindp@hotpop.com>
> Date: 2002/01/02 Wed PM 01:03:09 EST
>
>      I am facing some speed issues while generating PDF tables using
> FOP. I need to
> be able to generate the entire PDF document within 6-7 seconds. However,
> I found that a table with 500+ rows with about 6 or 7 columns takes the
> entire PDF doc
> about 20 seconds for generation. Is there some way to write the XSL:FO
> so that
> transformation occurs quickly. 

I don't know FOP well enough to know if there's some FOP-specific optimization you can do. But as far as your XSLT code, a couple observations....

(1) There seems to be a stray "</fo:block></xsl:for-each>" set of end tags at the very end of the code you posted. (Presumably just a copy/paste/data entry error, since otherwise the transformation wouldn't even start.)

(2) A pseudo-code version of the XSLT might look something like this:

   For each TABLE element in source tree:
      [do some stuff]
      Build a table in result tree
         Set up column sizes
         For each SCHEMA/COLUMN descendant of this TABLE element:
            [do some stuff]
            Under certain conditions:
               Jump back to top of source tree to get value of
                  root element's "type" attribute

         Build table header row:
            [do some stuff]
            For each SCHEMA/COLUMN descendant of this TABLE element:
               [do some stuff]

         [do some more stuff]
      Close the table

A couple things occurred to me about this. First, at the point where you go back up to the type attribute of the root ReportXMLFormat element, you may be churning unnecessarily -- depending on how often the controlling condition is met and, I guess, on whether the XSLT engine in question is cacheing source-tree stuff it's already retrieved. It might be more efficient to set up a variable outside the scope of the outermost xsl:for-each, to retrieve the value of that attribute just once.

The second and I think bigger problem MAY be that you've got two xsl:for-each's for the same source-tree content (the SCHEMA/COLUMN descendants of the source's current TABLE element) within the outermost xsl:for-each. Maybe it's not possible, maybe it is, but I think you might want to try somehow combining those two into one. If it's not possible, this is a long shot but you might also try replacing each of those two inner xsl:for-each loops with an xsl:apply-templates, using the mode attribute something like the following:

    <xsl:apply-templates select="SCHEMA/COLUMN" mode="col"/>
     ....
    <xsl:apply-templates select="SCHEMA/COLUMN" mode="cell"/>

    <xsl:template match="SCHEMA/COLUMN" mode="col">
       [column-related processing]
    </xsl:template>

    <xsl:template match="SCHEMA/COLUMN" mode="cell">
       [cell-related processing]
    </xsl:template>

This should only make a difference, I guess, if the XSLT engine processes xsl:apply-templates loops more efficiently than xsl:for-each loops, but it may be worth a try.


===================================
"I almost had a psychic girlfriend but she left me 
before we met." (unknown, possibly Steven Wright)

Received on Wednesday, 2 January 2002 08:26:37 UTC