RE: Large PDF - Performance
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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Large PDF - Performance
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Large PDF - Performance
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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Large PDF - Performance
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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Large PDF - Performance
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Large PDF - Performance
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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Large PDF - Performance
On Nov 10, 2005, at 19:57, [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Large PDF - Performance
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
