Re: Minimising FOP Runtimes
A time of 4 to 5 seconds for a 3..4 page document is very slow for modern machines. - Check for warm-up times. It may pay off to reuse the driver object. by the way, is ir re-entrant? (could be used by multiple threads at the same time to render different pdf's)? - Check JVM memory settings. - If the time includes XSLT, check without it. There are people out there capable of writing *horribly* inefficient XSLT. - Invest in a profiler. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Stan Pinte. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Minimising FOP Runtimes
Stan Pinte wrote: by the way, is ir re-entrant? (could be used by multiple threads at the same time to render different pdf's)? No, the rendering methods are all synchronized. If you want to take advantage of multiple threads you probably have to implement a pool. In most cases however rendering is CPU bound, and you need some rather expensive iron, perhaps MP, in order to get really something out of paralell rendering. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Minimising FOP Runtimes
I have been working on creating a three tier system that per client requests gets data from a database, pumps this into a PDF via FOP XSL/XML processing, then sends the resulting PDF back to the client for display. This project is reaching its end and creating a 3 or 4 page document usually takes 4 or 5 seconds (this is just the FOP processing aspect). Now this is acceptable but there is no harm in hunting down speed improvements. Having read through (and implemented any relevant suggestions) the FOP documentation regarding speed, I thought it would also be a good idea to speak to the people that use this application on a daily basis, as experience is invaluable when it comes to this type of thing. Regards Manuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Minimising FOP Runtimes
Manuel Reyes wrote: I have been working on creating a three tier system that per client requests gets data from a database, pumps this into a PDF via FOP XSL/XML processing, then sends the resulting PDF back to the client for display. This project is reaching its end and creating a 3 or 4 page document usually takes 4 or 5 seconds (this is just the FOP processing aspect). Now this is acceptable but there is no harm in hunting down speed improvements. Having read through (and implemented any relevant suggestions) the FOP documentation regarding speed, I thought it would also be a good idea to speak to the people that use this application on a daily basis, as experience is invaluable when it comes to this type of thing. A time of 4 to 5 seconds for a 3..4 page document is very slow for modern machines. - Check for warm-up times. It may pay off to reuse the driver object. - Check JVM memory settings. - If the time includes XSLT, check without it. There are people out there capable of writing *horribly* inefficient XSLT. - Invest in a profiler. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Minimising FOP Runtimes
On Wed, 2003-12-10 at 18:42, J.Pietschmann wrote: Manuel Reyes wrote: I have been working on creating a three tier system that per client requests gets data from a database, pumps this into a PDF via FOP XSL/XML processing, then sends the resulting PDF back to the client for display. This project is reaching its end and creating a 3 or 4 page document usually takes 4 or 5 seconds (this is just the FOP processing aspect). Now this is acceptable but there is no harm in hunting down speed improvements. Having read through (and implemented any relevant suggestions) the FOP documentation regarding speed, I thought it would also be a good idea to speak to the people that use this application on a daily basis, as experience is invaluable when it comes to this type of thing. A time of 4 to 5 seconds for a 3..4 page document is very slow for modern machines. - Check for warm-up times. It may pay off to reuse the driver object. - Check JVM memory settings. - If the time includes XSLT, check without it. There are people out there capable of writing *horribly* inefficient XSLT. - Invest in a profiler. I definitely agree with that. Generate the '.fo' separately, say with command-line Xalan and then generate your PDF with command-line Fop. This may take more resources than a 'pipeline' approach like Cocoon but will tell you which step is more expensive. You will need to do this anyway if you wish to run a profiler. Has anyone tried CatchXSL at www.xslprofiler.org ? It seems to work and has a nice UI but I didn't grok it in the few minutes I played with it. (I suppose one could intentionally write some bad XSL to demonstrate the use of this tool.) Check your 'java' command. There are two versions of the JVM available(on professional OS's anyway) which are selectable as 'java -server' and 'java -client' respectively. I found a benefit of about 10% from the -server version. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- John Austin [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
