You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by Danny <da...@gainergroup.com> on 2005/11/10 18:39:40 UTC
Large PDF - Performance
I cannot seem to get the performance that I need for this report.
I have tried all of the suggestions that I have found, mostly:
removal of the # of n page numbering
multiple page-sequences
Right now it takes 4 min 13 sec (from command line) to produce a pdf of 1000
TRANSACTION elements (from attached detrpt1.xml) ** this xml contains only 1
TRANSACTION element.
I have also attached
- DetailRpt.xsl and RptStyle.xsl - the FO files
Am I missing something?
This pdf is 1001 pages when rendered. Is that approaching the sensible
limit of fop?
Hopefully I have provided the correct information.
Any help is appreciated.
Thanks
Danny Gallagher
The Gainer Group
6525 The Corners Parkway
Suite 215
Norcross Ga, 30092
Re: Large PDF - Performance
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Nov 10, 2005, at 18:39, Danny wrote:
Hi,
> I cannot seem to get the performance that I need for this report.
>
> I have tried all of the suggestions that I have found, mostly:
> removal of the # of n page numbering
> multiple page-sequences
>
> Right now it takes 4 min 13 sec (from command line) to produce a
> pdf of 1000
> TRANSACTION elements (from attached detrpt1.xml) ** this xml
> contains only 1
> TRANSACTION element.
Have you tried performing the XSL transformation only, to see whether
that is the bottleneck? Or is it really the FO to PDF step that
performs badly?
If the XSLT stage takes too much time, then either the stylesheet
needs revising, or you could try a different XSLT processor (Saxon
instead of Xalan).
Another possibility: I remember a thread from about a month ago on
fop-users where the OP claimed that using Crimson as XML parser
(instead of Xerces which is the default shipped with FOP) caused a
performance improvement of 3000%. This could also be worth trying,
since your XML input would be rather large...
HTH!
Greetz,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Large PDF - Performance
Posted by Chris Bowditch <bo...@hotmail.com>.
Danny wrote:
> Nothing else changed that I am aware of.
>
> I'm working with it now, I'm sure it is something obvious, I just don't see
> it yet.
>
> I am using fop 0.20.5.
>
> I read in some of the mail list messages that there is a fix for some memory
> leak? problems in fop trunk involving tables.
The improvements to memory usage for tables that you are referring to,
are improvements to the maintenance code AKA 0.20.x. These improvements
are available by downloading the tip of the maintenance code branch from
SVN.
>
> Has anyone had any experience with moving from 0.20.5 to trunk and the
> effect on performance involving the use of table?
No, we've yet to do any bench mark testing on the new 0.90 version. I
will be interested to hear from anyone who has.
<snip/>
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
RE: Large PDF - Performance
Posted by Danny <da...@gainergroup.com>.
Nothing else changed that I am aware of.
I'm working with it now, I'm sure it is something obvious, I just don't see
it yet.
I am using fop 0.20.5.
I read in some of the mail list messages that there is a fix for some memory
leak? problems in fop trunk involving tables.
Has anyone had any experience with moving from 0.20.5 to trunk and the
effect on performance involving the use of table?
Thanks
Danny Gallagher
The Gainer Group
6525 The Corners Parkway
Suite 215
Norcross Ga, 30092
-----Original Message-----
From: Andreas L Delmelle [mailto:a_l.delmelle@pandora.be]
Sent: Saturday, November 12, 2005 8:43 AM
To: fop-users@xmlgraphics.apache.org
Subject: Re: Large PDF - Performance
On Nov 12, 2005, at 01:03, Danny wrote:
Hi,
> Ok, so continuing from where I was.
>
> I plugged saxon into my application (JAVA) code.
> <snip />
> So that all worked great, for a little while.
>
> Now the report is taking as long as it did before for some reason
> and I have
> no idea why.
Strange indeed... So the first few runs actually went faster than
before, and then all of a sudden performance dropped again?
Unfortunately, based on what you have shared with us, it's quite
difficult to tell what the problem might be.
You're absolutely sure nothing else has changed in between (however
insignificant the change might appear)?
BTW: What version of FOP are you using? 0.20.5 or FOP Trunk?
Greetz,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Large PDF - Performance
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Nov 12, 2005, at 01:03, Danny wrote:
Hi,
> Ok, so continuing from where I was.
>
> I plugged saxon into my application (JAVA) code.
> <snip />
> So that all worked great, for a little while.
>
> Now the report is taking as long as it did before for some reason
> and I have
> no idea why.
Strange indeed... So the first few runs actually went faster than
before, and then all of a sudden performance dropped again?
Unfortunately, based on what you have shared with us, it's quite
difficult to tell what the problem might be.
You're absolutely sure nothing else has changed in between (however
insignificant the change might appear)?
BTW: What version of FOP are you using? 0.20.5 or FOP Trunk?
Greetz,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
RE: Large PDF - Performance
Posted by Danny <da...@gainergroup.com>.
Ok, so continuing from where I was.
I plugged saxon into my application (JAVA) code.
1000 TRANSACTION element report (report button click in application to pdf
display to user)
Before using xalan (4 minutes 20 seconds)
Now using saxon (1 minute 45 seconds)
The only change that I had to make to the application was to set the system
property
javax.xml.transform.TransformerFactory=net.sf.saxon.TransformerFactoryImpl
so that the application would use saxon instead of the default (xalan).
And adding the saxon8.jar, of course.
So that all worked great, for a little while.
Now the report is taking as long as it did before for some reason and I have
no idea why. I verified that the application is using the saxon transformer
in two ways:
1. By specifying the xsl:vendor in the xsl.
2. By making sure that the class that is returned from the
TransformerFactory is an instance of net.sf.saxon.Controller
I restarted the application multiple times, even rebooted my PC, to no
avail.
Anyone ever seen this type of behavior before?
Thanks
Danny Gallagher
The Gainer Group
6525 The Corners Parkway
Suite 215
Norcross Ga, 30092
-----Original Message-----
From: J.Pietschmann [mailto:j3322ptm@yahoo.de]
Sent: Friday, November 11, 2005 4:18 PM
To: fop-users@xmlgraphics.apache.org
Subject: Re: Large PDF - Performance
Andreas L Delmelle wrote:
> In this respect, it may prove worthwhile to track down whether this
> difference is really caused by the XSLT processor itself, or merely by
> the fact that Saxon comes bundled with its own XML parser (AElfred).
Saxon uses a more efficient internal data storage, and also has much
better optimizations, both static and run-time. I believe the more
compact data representation is the winner, which also allows
transformation up to ten times the size Xalan can manage.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Large PDF - Performance
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Andreas L Delmelle wrote:
> In this respect, it may prove worthwhile to track down whether this
> difference is really caused by the XSLT processor itself, or merely by
> the fact that Saxon comes bundled with its own XML parser (AElfred).
Saxon uses a more efficient internal data storage, and also has much
better optimizations, both static and run-time. I believe the more
compact data representation is the winner, which also allows
transformation up to ten times the size Xalan can manage.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Saxon8
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Nov 11, 2005, at 17:51, Daniel Brown wrote:
>
> This is the error
>
> java.lang.NoClassDefFoundError: java/lang/CharSequence
Hmm. Running on Java 1.3 perhaps? This interface is available in Java
as of version 1.4.
Cheers,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Saxon8
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Nov 11, 2005, at 18:03, Daniel Brown wrote:
>
> Sorry, I should add that this is using the JVM 1.3.1
>
> When I use the JVM 1.5 it doesn't want to get external XSLs, though.
What do you mean exactly by 'external'? Imported or included
stylesheets?
Cheers,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Saxon8
Posted by Daniel Brown <Da...@binarytree.com>.
Sorry, I should add that this is using the JVM 1.3.1
When I use the JVM 1.5 it doesn't want to get external XSLs, though.
Regards,
Daniel
Daniel Brown <Da...@binarytree.com>
11/11/2005 11:51 AM
Please respond to
fop-users@xmlgraphics.apache.org
To
fop-users@xmlgraphics.apache.org
cc
Subject
Re: Saxon8
This is the error
java.lang.NoClassDefFoundError: java/lang/CharSequence
at net.sf.saxon.Configuration.<init>(Configuration.java:66)
at
net.sf.saxon.TransformerFactoryImpl.<init>(TransformerFactoryImpl.java:42)
at java.lang.Class.newInstance0(Native Method)
at java.lang.Class.newInstance(Class.java:232)
at
javax.xml.transform.FactoryFinder.newInstance(FactoryFinder.java:97)
at
javax.xml.transform.FactoryFinder.findJarServiceProvider(FactoryFinder.java:275)
at javax.xml.transform.FactoryFinder.find(FactoryFinder.java:182)
at
javax.xml.transform.TransformerFactory.newInstance(TransformerFactory.java:100)
at
com.binarytree.xml.fo.Converters.convertXML2PDF(Converters.java:55)
at
com.binarytree.xml.fo.ConvertDBL_DOC.main(ConvertDBL_DOC.java:31)
Exception in thread "main"
Regards,
Daniel
Andreas L Delmelle <a_...@pandora.be>
11/11/2005 11:21 AM
Please respond to
fop-users@xmlgraphics.apache.org
To
fop-users@xmlgraphics.apache.org
cc
Subject
Re: Saxon8
On Nov 11, 2005, at 17:25, Daniel Brown wrote:
>
> I have tried to implement Saxon8.6 in place of Xalan but am getting
> errors. Are there other libraries I require?
What kinds of error are you talking about? There should be no need
for additional libraries...
Cheers,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Saxon8
Posted by Daniel Brown <Da...@binarytree.com>.
This is the error
java.lang.NoClassDefFoundError: java/lang/CharSequence
at net.sf.saxon.Configuration.<init>(Configuration.java:66)
at
net.sf.saxon.TransformerFactoryImpl.<init>(TransformerFactoryImpl.java:42)
at java.lang.Class.newInstance0(Native Method)
at java.lang.Class.newInstance(Class.java:232)
at
javax.xml.transform.FactoryFinder.newInstance(FactoryFinder.java:97)
at
javax.xml.transform.FactoryFinder.findJarServiceProvider(FactoryFinder.java:275)
at javax.xml.transform.FactoryFinder.find(FactoryFinder.java:182)
at
javax.xml.transform.TransformerFactory.newInstance(TransformerFactory.java:100)
at
com.binarytree.xml.fo.Converters.convertXML2PDF(Converters.java:55)
at
com.binarytree.xml.fo.ConvertDBL_DOC.main(ConvertDBL_DOC.java:31)
Exception in thread "main"
Regards,
Daniel
Andreas L Delmelle <a_...@pandora.be>
11/11/2005 11:21 AM
Please respond to
fop-users@xmlgraphics.apache.org
To
fop-users@xmlgraphics.apache.org
cc
Subject
Re: Saxon8
On Nov 11, 2005, at 17:25, Daniel Brown wrote:
>
> I have tried to implement Saxon8.6 in place of Xalan but am getting
> errors. Are there other libraries I require?
What kinds of error are you talking about? There should be no need
for additional libraries...
Cheers,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Saxon8
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Nov 11, 2005, at 17:25, Daniel Brown wrote:
>
> I have tried to implement Saxon8.6 in place of Xalan but am getting
> errors. Are there other libraries I require?
What kinds of error are you talking about? There should be no need
for additional libraries...
Cheers,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Saxon8
Posted by JB...@s-s-t.com.
I have tried to implement Saxon8.6 in place of Xalan but am getting
errors. Are there other libraries I require?
Regards,
Daniel
Hi, Daniel,
The Saxon distribution is self-contained, so you should need no other
libraries. It requires Java 1.5 (or Java 1.4 and some additional package
from Sun, but I just use 1.5, so I forget the details of that bit).
For questions like this, I recommend subscribing to
saxon-help@lists.sourceforge.net. Mike Kay is VERY good about answering
questions, often within just a few minutes (remember that he lives in
England, though, so don't expect much late in the day).
Jay Bryant
Bryant Communication Services
(presently consulting at Synergistic Solution Technologies)
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Saxon8
Posted by Daniel Brown <Da...@binarytree.com>.
I have tried to implement Saxon8.6 in place of Xalan but am getting
errors. Are there other libraries I require?
Regards,
Daniel
JBryant@s-s-t.com
11/11/2005 10:36 AM
Please respond to
fop-users@xmlgraphics.apache.org
To
fop-users@xmlgraphics.apache.org
cc
Subject
Re: Large PDF - Performance
> In this respect, it may prove worthwhile to track down whether
> this difference is really caused by the XSLT processor itself,
> or merely by the fact that Saxon comes bundled with its own
> XML parser (AElfred).
>From the Aelfred web site on Sourceforge:
"Saxon versions from 7.2 onwards no longer include a built-in XML parser.
This decision was taken because Saxon is now dependent on JDK 1.4, which
includes its own XML parser, and therefore the original reason for
bundling a parser with Saxon has disappeared."
That listing is a bit out of date, as the last couple versions (8.5 and
8.6) of Saxon use the 1.5 JDK.
So, versions 7 & 8 of Saxon (which provide access to XSLT 2.0) use
Crimson. Version 6.x uses Aelfred. I believe the OP mentioned using Saxon
8, so the parser in question is Crimson.
FWIW
Jay Bryant
Bryant Communication Services
(presently consulting at Synergistic Solution Technologies)
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Large PDF - Performance
Posted by JB...@s-s-t.com.
> In this respect, it may prove worthwhile to track down whether
> this difference is really caused by the XSLT processor itself,
> or merely by the fact that Saxon comes bundled with its own
> XML parser (AElfred).
>From the Aelfred web site on Sourceforge:
"Saxon versions from 7.2 onwards no longer include a built-in XML parser.
This decision was taken because Saxon is now dependent on JDK 1.4, which
includes its own XML parser, and therefore the original reason for
bundling a parser with Saxon has disappeared."
That listing is a bit out of date, as the last couple versions (8.5 and
8.6) of Saxon use the 1.5 JDK.
So, versions 7 & 8 of Saxon (which provide access to XSLT 2.0) use
Crimson. Version 6.x uses Aelfred. I believe the OP mentioned using Saxon
8, so the parser in question is Crimson.
FWIW
Jay Bryant
Bryant Communication Services
(presently consulting at Synergistic Solution Technologies)
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Large PDF - Performance
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Nov 11, 2005, at 15:27, Danny wrote:
> I plugged saxon into my application code.
>
> 1000 TRANSACTION element report (report button click in application
> to pdf
> display to user)
>
> Before using xalan (4 minutes 20 seconds)
>
> Now using saxon (1 minute 45 seconds)
>
> Quite a difference!
In this respect, it may prove worthwhile to track down whether this
difference is really caused by the XSLT processor itself, or merely
by the fact that Saxon comes bundled with its own XML parser (AElfred).
Greetz,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
RE: Large PDF - Performance
Posted by Danny <da...@gainergroup.com>.
I plugged saxon into my application code.
1000 TRANSACTION element report (report button click in application to pdf
display to user)
Before using xalan (4 minutes 20 seconds)
Now using saxon (1 minute 45 seconds)
Quite a difference!
Danny Gallagher
The Gainer Group
6525 The Corners Parkway
Suite 215
Norcross Ga, 30092
-----Original Message-----
From: Mike Trotman [mailto:mike.trotman@datalucid.com]
Sent: Friday, November 11, 2005 8:54 AM
To: fop-users@xmlgraphics.apache.org
Subject: Re: Large PDF - Performance
I tested several XSLT processors last year - on both Linux and Windows.
I also found that certain XPATH expressions produced significant
differences in processing time between the different processors.
(One surprise was that Saxon 6.5.3 (I think) took a long time with XPATH
expressions involving '../somexpathexpression'.
Just defining a variable that was '..' and using
'$variable/somexpathexpression' vastly improved things.)
So - I think XPATH between different processors is like SQL between
different relational databases.
They all do different optimisations.
You need to tune your XSLT for your processor.
Mike
Danny wrote:
>Thank you all for the suggestions.
>
>Here is what I have done so far, maybe this could help others with projects
>that they are working on. I ran a 1000 TRANSACTION element version of the
>detrpt1.xml through two different XSLT processors, both from the command
>line, so I could get an understanding of the XSL transformation time,
taking
>fop out of the equation.
>
>The two XSLT processors
>Xalan-j - version 2_7_0 - Processing time - 2 min 10 seconds
>Saxon - version 8 - Processing time - 2.5 seconds
>
>I was surprised to see such a huge difference in performance, but I believe
>I performed the benchmarks correctly, I was just creating a text file for
>the test, but each created a text file of the same size, with all the data
>from the xml present.
>
>So now I am plugging Saxon in to the actual application and I will see what
>I get.
>
>I will repost to the mail list, if anything that might be helpful to others
>comes up.
>
>Again, thanks for all the help.
>
>Danny Gallagher
>The Gainer Group
>6525 The Corners Parkway
>Suite 215
>Norcross Ga, 30092
>
>
>
>
Message Scanned by ClamAV on datalucid.com
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Large PDF - Performance
Posted by Mike Trotman <mi...@datalucid.com>.
I tested several XSLT processors last year - on both Linux and Windows.
I also found that certain XPATH expressions produced significant
differences in processing time between the different processors.
(One surprise was that Saxon 6.5.3 (I think) took a long time with XPATH
expressions involving '../somexpathexpression'.
Just defining a variable that was '..' and using
'$variable/somexpathexpression' vastly improved things.)
So - I think XPATH between different processors is like SQL between
different relational databases.
They all do different optimisations.
You need to tune your XSLT for your processor.
Mike
Danny wrote:
>Thank you all for the suggestions.
>
>Here is what I have done so far, maybe this could help others with projects
>that they are working on. I ran a 1000 TRANSACTION element version of the
>detrpt1.xml through two different XSLT processors, both from the command
>line, so I could get an understanding of the XSL transformation time, taking
>fop out of the equation.
>
>The two XSLT processors
>Xalan-j - version 2_7_0 - Processing time - 2 min 10 seconds
>Saxon - version 8 - Processing time - 2.5 seconds
>
>I was surprised to see such a huge difference in performance, but I believe
>I performed the benchmarks correctly, I was just creating a text file for
>the test, but each created a text file of the same size, with all the data
>from the xml present.
>
>So now I am plugging Saxon in to the actual application and I will see what
>I get.
>
>I will repost to the mail list, if anything that might be helpful to others
>comes up.
>
>Again, thanks for all the help.
>
>Danny Gallagher
>The Gainer Group
>6525 The Corners Parkway
>Suite 215
>Norcross Ga, 30092
>
>
>
>
Message Scanned by ClamAV on datalucid.com
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
RE: Large PDF - Performance
Posted by Danny <da...@gainergroup.com>.
Thank you all for the suggestions.
Here is what I have done so far, maybe this could help others with projects
that they are working on. I ran a 1000 TRANSACTION element version of the
detrpt1.xml through two different XSLT processors, both from the command
line, so I could get an understanding of the XSL transformation time, taking
fop out of the equation.
The two XSLT processors
Xalan-j - version 2_7_0 - Processing time - 2 min 10 seconds
Saxon - version 8 - Processing time - 2.5 seconds
I was surprised to see such a huge difference in performance, but I believe
I performed the benchmarks correctly, I was just creating a text file for
the test, but each created a text file of the same size, with all the data
from the xml present.
So now I am plugging Saxon in to the actual application and I will see what
I get.
I will repost to the mail list, if anything that might be helpful to others
comes up.
Again, thanks for all the help.
Danny Gallagher
The Gainer Group
6525 The Corners Parkway
Suite 215
Norcross Ga, 30092
-----Original Message-----
From: Andreas L Delmelle [mailto:a_l.delmelle@pandora.be]
Sent: Thursday, November 10, 2005 3:16 PM
To: fop-users@xmlgraphics.apache.org
Subject: Re: Large PDF - Performance
On Nov 10, 2005, at 21:10, J.Pietschmann wrote:
> Andreas L Delmelle wrote:
>>> Oh, you might want to look into pre-compiled stylesheets, too. Saxon
>>> supports those. I don't know about Xalan.
>> It does: see http://xml.apache.org/xalan-j/xsltc_usage.html
>
> Well, XSLTC compiles XSLT into Java. Compiled style sheets are usually
> a bit less drastic, it just means the style sheet is kept in a
> javax.xml.transform.Templates object.
Sorry, my mistake.
> This saves parsing the XML into an internal data structure and
> static optimizations.
> Standard Xalan supports compiled style sheets in the latter sense too.
> Not that XSLTC is actually a completely separate code base and has
> quite a bit more problems than standard Xalan.
Yep. Still Sun has adopted it and made it part of Java 1.5. If the
stylesheet can be compiled into Java w.o. problems, it is noticeably
quite a bit faster (for all but the first run, evidently).
Cheers,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Large PDF - Performance
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Nov 10, 2005, at 21:10, J.Pietschmann wrote:
> Andreas L Delmelle wrote:
>>> Oh, you might want to look into pre-compiled stylesheets, too. Saxon
>>> supports those. I don't know about Xalan.
>> It does: see http://xml.apache.org/xalan-j/xsltc_usage.html
>
> Well, XSLTC compiles XSLT into Java. Compiled style sheets are usually
> a bit less drastic, it just means the style sheet is kept in a
> javax.xml.transform.Templates object.
Sorry, my mistake.
> This saves parsing the XML into an internal data structure and
> static optimizations.
> Standard Xalan supports compiled style sheets in the latter sense too.
> Not that XSLTC is actually a completely separate code base and has
> quite a bit more problems than standard Xalan.
Yep. Still Sun has adopted it and made it part of Java 1.5. If the
stylesheet can be compiled into Java w.o. problems, it is noticeably
quite a bit faster (for all but the first run, evidently).
Cheers,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Large PDF - Performance
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Andreas L Delmelle wrote:
>> Oh, you might want to look into pre-compiled stylesheets, too. Saxon
>> supports those. I don't know about Xalan.
>
> It does: see http://xml.apache.org/xalan-j/xsltc_usage.html
Well, XSLTC compiles XSLT into Java. Compiled style sheets are usually
a bit less drastic, it just means the style sheet is kept in a
javax.xml.transform.Templates object. This saves parsing the XML into
an internal data structure and static optimizations. Standard Xalan
supports compiled style sheets in the latter sense too.
Not that XSLTC is actually a completely separate code base and has
quite a bit more problems than standard Xalan.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Large PDF - Performance
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Nov 10, 2005, at 19:57, JBryant@s-s-t.com wrote:
<snip />
>
> Oh, you might want to look into pre-compiled stylesheets, too. Saxon
> supports those. I don't know about Xalan.
It does: see http://xml.apache.org/xalan-j/xsltc_usage.html
Greetz,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Large PDF - Performance
Posted by JB...@s-s-t.com.
Hi, Danny,
IMHO, 1001 pages does not approach FOP's limit. I have produced documents
more than twice that size with FOP.
Also, when I produce those documents (data dictionaries for my client),
FOP takes about two minutes to do its thing. However, I do not use Xalan
as my XSLT processor. I use Saxon for the XSLT processor and then use FOP
to transform the FO file into PDF. For the whole process, I need about
three minutes (one for Saxon and two for FOP).
I started using Saxon 8 (currently 8.6) to get some XSLT 2.0 features and
then found that Saxon is a better and faster processor in addition to the
XSLT 2.0 features.
Oh, you might want to look into pre-compiled stylesheets, too. Saxon
supports those. I don't know about Xalan.
FWIW
Jay Bryant
Bryant Communication Services
(presently consulting at Synergistic Solution Technologies)
"Danny" <da...@gainergroup.com>
11/10/2005 11:39 AM
Please respond to
fop-users@xmlgraphics.apache.org
To
<fo...@xml.apache.org>
cc
Subject
Large PDF - Performance
I cannot seem to get the performance that I need for this report.
I have tried all of the suggestions that I have found, mostly:
removal of the # of n page numbering
multiple page-sequences
Right now it takes 4 min 13 sec (from command line) to produce a pdf of
1000
TRANSACTION elements (from attached detrpt1.xml) ** this xml contains only
1
TRANSACTION element.
I have also attached
- DetailRpt.xsl and RptStyle.xsl - the FO files
Am I missing something?
This pdf is 1001 pages when rendered. Is that approaching the sensible
limit of fop?
Hopefully I have provided the correct information.
Any help is appreciated.
Thanks
Danny Gallagher
The Gainer Group
6525 The Corners Parkway
Suite 215
Norcross Ga, 30092
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org