Re: FOP performance on Win98/JRE 1.3.1
Hi Lukas, mixing support classes such as xerces, batik etc. is *not* a good idea. The danger is that you will be getting errors for proper code due to the not tested "blend of jars". I can tell you this from my own experience. It may work, though ... Stephan - Original Message - From: "Lukas Pietsch" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, December 12, 2001 9:51 AM Subject: Re: FOP performance on Win98/JRE 1.3.1 > I use FOP with Xalan and I have noticed that the performance is really > better with the last version of Xalan (the speed is multiply by 10) !!! That sounds interesting. FOP 0.20.2 is being distributed with a file called xalan-2.0.0.jar. Is it technically okay to just go and grab a newer version of a Xalan jar file somwhere and put it in that directory instead of the old one? Lukas (with some revived hope...) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP performance on Win98/JRE 1.3.1
Just a thought... did anybody try FOP with jRockit JVM? James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP performance on Win98/JRE 1.3.1
On Wednesday 12 December 2001 14:42, Cyril Rognon wrote: > before making any modification to your docbook stylesheet, I suggest you > simply use some XML parser feature to deactivate the DTD validation and DTD > loading. Yes, of course to actually solve the problem (assuming DTD fetching *is* the problem), I agree. But for a quick test, trying to find out if DTD fetching is the problem, I'd rather take out the DOCTYPE from a test document - quicker and I wouldn't have to mess with configuration settings. - Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP performance on Win98/JRE 1.3.1
relax, before making any modification to your docbook stylesheet, I suggest you simply use some XML parser feature to deactivate the DTD validation and DTD loading. Every major XML parser use these feature that you can configure (see Xerces for instance). This way you will not endenger the docbook code you are using or introduce any bugs :) By the way, apart from the lack of speed, do docbook stylesheet generate a good looking FO ? (I mean PDF) At 14:35 12/12/2001 +0100, you wrote: >On Wednesday 12 December 2001 12:24, Lukas Pietsch wrote: > > What's still slow is the preceding docbook-to-.fo conversion. > >One thing I've seen is document referring to a DTD using an http:// URL. > >This is ok, but usually the parser will go out to the Internet to fetch the >DTD, which can slow down the process noticeably. > >I'd suggest checking your documents or remove any DOCTYPE declarations to see >if it makes a difference. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP performance on Win98/JRE 1.3.1
On Wednesday 12 December 2001 12:24, Lukas Pietsch wrote: > What's still slow is the preceding docbook-to-.fo conversion. One thing I've seen is document referring to a DTD using an http:// URL. This is ok, but usually the parser will go out to the Internet to fetch the DTD, which can slow down the process noticeably. I'd suggest checking your documents or remove any DOCTYPE declarations to see if it makes a difference. -- -- Bertrand Delacrétaz, www.codeconsult.ch -- web technologies consultant - OO, Java, XML, C++ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP performance on Win98/JRE 1.3.1
Hello,
okay, here's the result:
with the new version of Xalan (2.2.D14), the .fo to .pdf part of the conversion is
really a good deal faster. ("[DEBUG]: Avg render time: 1050ms/page"). What's still
slow is the preceding docbook-to-.fo conversion. And I've also found out that it makes
no big difference whether I do this with FOP or with xt. It takes about 25 seconds for
the same (tiny) test document either way. So maybe it's really the complexity of the
docbook xsl stylesheets that's the main culprit?
Lukas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: FOP performance on Win98/JRE 1.3.1
Normally, there's no problem... The Xalan version I used is the 2.2.D11 (the really last is the 2.2.D14). Solange Desseignes -Message d'origine- De : Lukas Pietsch [mailto:[EMAIL PROTECTED]] Envoyé : mercredi 12 décembre 2001 09:52 À : [EMAIL PROTECTED] Objet : Re: FOP performance on Win98/JRE 1.3.1 > I use FOP with Xalan and I have noticed that the performance is really > better with the last version of Xalan (the speed is multiply by 10) !!! That sounds interesting. FOP 0.20.2 is being distributed with a file called xalan-2.0.0.jar. Is it technically okay to just go and grab a newer version of a Xalan jar file somwhere and put it in that directory instead of the old one? Lukas (with some revived hope...) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP performance on Win98/JRE 1.3.1
> I use FOP with Xalan and I have noticed that the performance is really > better with the last version of Xalan (the speed is multiply by 10) !!! That sounds interesting. FOP 0.20.2 is being distributed with a file called xalan-2.0.0.jar. Is it technically okay to just go and grab a newer version of a Xalan jar file somwhere and put it in that directory instead of the old one? Lukas (with some revived hope...) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: FOP performance on Win98/JRE 1.3.1
>Well, okay, I do understand how I could achieve this--just spend a couple of hundred bucks. ;-) PC133, 512MB = 40 USD. S. -Original Message- From: Lukas Pietsch [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 12, 2001 10:46 AM To: [EMAIL PROTECTED] Subject: Re: FOP performance on Win98/JRE 1.3.1 Thanks, James, for the detailed comments. Not that I understood everything of it--I'm afraid I'm rather unexperienced with Java in general. Your suggestions sound quite convincing, only I don't know how to actually carry them out. Now maybe what follows is terribly boring newbie stuff. In that case, perhaps somebody could point me to some relevant tutorial or similar stuff on the web? (1) making the JVM survive a single FOP run or a single document conversion. How? The only way I know of invoking FOP is by saying "java org.apache.fop.apps.Fop" in a .bat program. (2) Adjusting JVM memory settings. How? Okay, I've found something about -Xms and -Xmx commandline parameters, but how do I find out what the present default values are? (3) Eden heap space settings. No idea what those are, let alone how I could change them... (4) Increasing physical memory. Well, okay, I do understand how I could achieve this--just spend a couple of hundred bucks. ;-) But are you really suggesting it's hopeless to run FOP on a 128MB machine? Lukas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP performance on Win98/JRE 1.3.1
Thanks, James, for the detailed comments. Not that I understood everything of it--I'm afraid I'm rather unexperienced with Java in general. Your suggestions sound quite convincing, only I don't know how to actually carry them out. Now maybe what follows is terribly boring newbie stuff. In that case, perhaps somebody could point me to some relevant tutorial or similar stuff on the web? (1) making the JVM survive a single FOP run or a single document conversion. How? The only way I know of invoking FOP is by saying "java org.apache.fop.apps.Fop" in a .bat program. (2) Adjusting JVM memory settings. How? Okay, I've found something about -Xms and -Xmx commandline parameters, but how do I find out what the present default values are? (3) Eden heap space settings. No idea what those are, let alone how I could change them... (4) Increasing physical memory. Well, okay, I do understand how I could achieve this--just spend a couple of hundred bucks. ;-) But are you really suggesting it's hopeless to run FOP on a 128MB machine? Lukas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: FOP performance on Win98/JRE 1.3.1
Hello ! I use FOP with Xalan and I have noticed that the performance is really better with the last version of Xalan (the speed is multiply by 10) !!! Solange Desseignes -Message d'origine- De : IvanLatysh [mailto:[EMAIL PROTECTED]] Envoyé : mardi 11 décembre 2001 18:42 À : [EMAIL PROTECTED] Objet : Re: FOP performance on Win98/JRE 1.3.1 Hello, James! You wrote to <[EMAIL PROTECTED]> on Tue, 11 Dec 2001 17:28:25 +: JR> The performance of FOP needs quite a bit of work. At least thats the JR> impression I get from many people round here. However, its really JR> new software ( hanve version 0.20 I would imagine ), and I think JR> that that probably the coders are working on getting the JR> functionality there before spending time concentrating on the JR> performance. I think performance only question of time. But one more: What about German documentation for some classes. Maybe you guys could notify all developers to use English. Because "I am stack in a middle with you" (c) famous song. I couldn't move from dead point with my application. I do understand that now some thing are not ready yet, but I think you should pay attention to preview panel and print method. And, by the way - great job guys. --- Yours sincerely, Ivan Latysh. [EMAIL PROTECTED] http://ivan.yourmail.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP performance on Win98/JRE 1.3.1
Hello, James! You wrote to <[EMAIL PROTECTED]> on Tue, 11 Dec 2001 17:28:25 +: JR> The performance of FOP needs quite a bit of work. At least thats the JR> impression I get from many people round here. However, its really JR> new software ( hanve version 0.20 I would imagine ), and I think JR> that that probably the coders are working on getting the JR> functionality there before spending time concentrating on the JR> performance. I think performance only question of time. But one more: What about German documentation for some classes. Maybe you guys could notify all developers to use English. Because "I am stack in a middle with you" (c) famous song. I couldn't move from dead point with my application. I do understand that now some thing are not ready yet, but I think you should pay attention to preview panel and print method. And, by the way - great job guys. --- Yours sincerely, Ivan Latysh. [EMAIL PROTECTED] http://ivan.yourmail.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP performance on Win98/JRE 1.3.1
The performance of FOP needs quite a bit of work. At least thats the
impression I get from many people round here. However, its really new
software ( hanve version 0.20 I would imagine ), and I think that that
probably the coders are working on getting the functionality there
before spending time concentrating on the performance.
One thing you will find is that the first run through the code takes by
far the longest time. The JVM needs to load all the relevant classes,
initialise them, and that kind of thing. Once this has been done, the
JVM (if you have it switched on) will potentially compile some of the
code, rather than interpret the java byte code. This can improve the
speed significantly.
The other thing you need to check is for your JVM memory settings. If
you use the default, then FOP may cause the free heap space to go
dangerously low, increasing the frequency of full GC runs. These are
best avoided, as all threads are suspended during the GC phase. Adding
memory to the heap can cause these problems to diminish, (perhaps adding
up to 256m, using the -Xms and -Xmx flags ), but then you may find that
full GCs take too long ...You may also want to take a look at the Eden
heap space settings, these could significantly increase speed if
slowdown is due to memory & GC issues, as a result of short-lived objects.
Of course if you are adding memory to the JVM heap, then you should also
make sure that you have anough physical memory, or this may cause VM
paging at the OS level. I would say 256 or 512M as minimum requirement.
When running on UNIX i have seen a significant amount of kernel CPU
usage, which i cannot really account for
In short, then. If you want FOP to run more quickly, render more than
one document during the JVM lifetime. The first rendering will be slow,
but subsequent ones much more speedy. And add memory.
Hope this helps
James
Lukas Pietsch wrote:
>
>
>
> Hello,
>
> (I asked this question on the [EMAIL PROTECTED] list first, but was told to
> better go here with it.)
>
> I'm new to xsl-fo and related matters and I've just managed to set up FOP
> (0.20.2) and make a few test runs. I'm now wondering a bit about its
> performance. Parsing a single test xml document (a docbook chapter) with
> just a few words in it, transforming it with the docbook xsl stylesheets
> and outputting to pdf takes more than 40 seconds. It's fifteen seconds
> before I even get the debug line ("[DEBUG]: using SAX parser
> org.apache.xerces.parsers.SAXParser"). Afterwards, it says "[DEBUG]: Avg
> render time: 10600ms/page".
> Is this considered normal? It makes me wonder if my FOP installation (or
> indeed my Java installation) is set up correctly. Cyril Rognon on the
> www-xsl-fo list confirmed he found it rather too slow.
>
> This is on Windows 98, with a 500MHz AMD-K6 processor and 128 MB memory,
> using FOP 0.20.2 (sorry, I wrongly said 0.20.0 in the earlier mail) and the
> Java JRE 1.3.1.
>
> What could I do to diagnose the problem better?
>
> Thanks for any pointers,
>
> Lukas Pietsch
>
>
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
