W3C home > Mailing lists > Public > www-xsl-fo@w3.org > January 2002

Re: speed issues with XSL:FO tables.

From: Arvind Parthasarathy <arvindp@HotPOP.com>
Date: Wed, 02 Jan 2002 23:15:44 +0530
Message-ID: <3C334748.5090405@HotPOP.com>
To: "John E.Simpson" <simpson@polaris.net>
Cc: fop-users@apache.org, www-xsl-fo@w3.org
Hi ,
          Thanks a lot, John,  for your help. Your interpretation of the 
snippet that I'd sent in my
earlier mail is correct. I'm still quite a novice at both XSL and XSL:FO.
          Although, your steps would help optimizing the XSL 
stylesheet... that's not where I'm
facing the problem. I need to optimize the FO part, some way.
           My Java program does the following :-
1. Generates the XML data (takes virtually no time.)
2. Uses the XSL stylesheet (using Xalan) to convert the XML to FO.
3. Uses FOP to convert the FO to PDF.

At the begining and the end of each step, I used a
System.out.println((new Date(System.getCurrTimeMillis()).toString());
to see how much time each step takes. And step 3 takes 20 seconds while 
step 2 takes only
a second as mentioned in my previous mail. This happens only when tables 
are used. It's not
a problem when big tables aren't used.

Any help on this would be greatly appreciated. John's help offer is 
appreciated too !!!


John E.Simpson wrote:

>> From: Arvind Parthasarathy <arvindp@hotpop.com> <mailto: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 12:42:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:58:25 UTC