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 Martin Kristensen <mk...@reklamedata.dk> on 2008/03/31 11:04:25 UTC
Performance problems when generating TIFF on IBM iSeries
Hello,
I'm working on generating some PDF and TIFF files with FOP 0.94 on an IBM iSeries OS400 JVM 1.5. I tried ExampleFO2PDF.java which worked fine, except when I changed the output type to TIFF, the execution time went from a few seconds to more than a minute. I also tried PNG, which was just as slow, so it's apparently bitmapped graphics in general that suffers.
On my Windows box TIFF is about as fast as PDF, so my first guess was that it might be caused by running in java.awt.headless=true mode on the IBM server because of lack of GUI, but setting it to headless on my PC doesn't have any effect on the speed. The second clue was that Java's font rendering might be the cause, since the execution time correlates to the number of characters in the picture. But at least a test of java.awt.Graphics2D.drawString indicates that it's just as fast on the iSeries.
Another factor is the resolution, which seems to influence the execution time exponentially, e.g. going from 100 to 200 DPI makes it more than 10 times slower. Unfortunately the output has to be in a fairly good resolution in order to look good when it's faxed, so it's not an option to make it fast that way.
So I wonder whether this performance issue on the OS400 JVM is a known problem, or if anyone have any other suggestions. Otherwise the solution will probably be to run the FOP functionality as a web service on a Windows or Linux server, but it's of course better if it can all run on the iSeries.
Best regards,
Martin Kristensen / Developer
Reklamedata A/S · Vordingborggade 18-22 · DK-2100 København Ø
Tel +45 35 272 222 · Fax +45 35 272 299 · Web www.reklamedata.dk <http://www.reklamedata.dk>
Tel Dir +45 35 272 247 · Mob +45 51990779 · Mail mk@reklamedata.dk <ma...@reklamedata.dk>
Re: Performance problems when generating TIFF on IBM iSeries
Posted by Andreas Delmelle <an...@telenet.be>.
On Apr 1, 2008, at 13:44, Martin Kristensen wrote:
> I haven't been able to switch to another JVM as we apparently only
> have
> this one installed, and it's not an option to install others for some
> reason. I have tried to play a bit around with the memory settings,
> with
> no effect, but apparently it doesn't use that much memory. It's also a
> very simple page with a few lines of text (the "projectteam" example
> included with FOP.) So I don't think memory consumption per se is the
> problem, it's more likely some part of java.awt that's implemented
> very
> inefficiently on the OS400 JVM.
Concerning your initial suspicion of the font-rendering:
I do seem to remember someone mentioning that FOP's font-related code
generates a rather high number of calls into the AWT classes for the
related output formats (but that was quite a while ago). It's not so
much the drawString() method, as stuff like
java.awt.FontMetrics.getStringBounds(), which is called once for each
character (!), and unfortunately, the result is not buffered anywhere
for the same character in the same font... If this method is poorly
implemented on the side of the JVM, the effect on FOP's Java2D
rendering could be quite noticeable, I think.
> One of my colleagues suggested trying Sun's PDFRenderer, which can
> convert PDFs to bitmapped graphics (https://pdf-
> renderer.dev.java.net/)
> This works fine, except it's just as slow (7 minutes for a faxable
> TIFF.) So I guess it uses awt as well.
Probably, but it could also be partly caused by the fact that the PDF
needs to be re-parsed before converting it to graphics.
> But there's a lot of other Java
> based PDF->graphics converters out there, so I'll keep trying. Anyone
> happen to know one that doesn't use awt?
I doubt it somehow, but good luck anyway!
Cheers
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
RE: Performance problems when generating TIFF on IBM iSeries
Posted by Martin Kristensen <mk...@reklamedata.dk>.
Thanks for the answer.
I haven't been able to switch to another JVM as we apparently only have
this one installed, and it's not an option to install others for some
reason. I have tried to play a bit around with the memory settings, with
no effect, but apparently it doesn't use that much memory. It's also a
very simple page with a few lines of text (the "projectteam" example
included with FOP.) So I don't think memory consumption per se is the
problem, it's more likely some part of java.awt that's implemented very
inefficiently on the OS400 JVM.
One of my colleagues suggested trying Sun's PDFRenderer, which can
convert PDFs to bitmapped graphics (https://pdf-renderer.dev.java.net/)
This works fine, except it's just as slow (7 minutes for a faxable
TIFF.) So I guess it uses awt as well. But there's a lot of other Java
based PDF->graphics converters out there, so I'll keep trying. Anyone
happen to know one that doesn't use awt?
Best regards,
Martin
-----Original Message-----
From: Andreas Delmelle [mailto:andreas.delmelle@telenet.be]
Sent: 31. marts 2008 22:45
To: fop-users@xmlgraphics.apache.org
Subject: Re: Performance problems when generating TIFF on IBM iSeries
On Mar 31, 2008, at 11:04, Martin Kristensen wrote:
Hi
> I'm working on generating some PDF and TIFF files with FOP 0.94 on
> an IBM iSeries OS400 JVM 1.5. I tried ExampleFO2PDF.java which
> worked fine, except when I changed the output type to TIFF, the
> execution time went from a few seconds to more than a minute. I
> also tried PNG, which was just as slow, so it's apparently
> bitmapped graphics in general that suffers.
>
> On my Windows box TIFF is about as fast as PDF, so my first guess
> was that it might be caused by running in java.awt.headless=true
> mode on the IBM server because of lack of GUI, but setting it to
> headless on my PC doesn't have any effect on the speed. The second
> clue was that Java's font rendering might be the cause, since the
> execution time correlates to the number of characters in the
> picture. But at least a test of java.awt.Graphics2D.drawString
> indicates that it's just as fast on the iSeries.
The whole Graphics2D implementation probably differs significantly in
the IBM JVM, and that is the biggest difference between PDF and TIFF/
PNG output. For the TIFF/PNG formats, FOP draws heavily on Java AWT
(= native code, platform/implementation dependent), while for PDF/PS
practically everything is handled within FOP itself.
> Another factor is the resolution, which seems to influence the
> execution time exponentially, e.g. going from 100 to 200 DPI makes
> it more than 10 times slower. Unfortunately the output has to be in
> a fairly good resolution in order to look good when it's faxed, so
> it's not an option to make it fast that way.
> So I wonder whether this performance issue on the OS400 JVM is a
> known problem, or if anyone have any other suggestions.
No experience with Java on iSeries over here, but I just read that
the special OS400 JVM is less performant than IBM's Standard JVM
(which is used on IBM's Linux/AIX platform), and that IBM was going
to gradually phase out the former in favor of the latter. As of i5/
OS, the standard JVM would have been added as an option (?)
Is it already an option in your environment to try to use a different
IBM JVM?
> Otherwise the solution will probably be to run the FOP
> functionality as a web service on a Windows or Linux server, but
> it's of course better if it can all run on the iSeries.
Also, check thoroughly whether the slowdown is not created by garbage-
collection (or lack thereof). We have received a couple of reports
indicating supposed memory-leaks in FOP. As far as I recall, all
running on IBM JVM's. I never succeeded in reproducing them with a
Sun JVM on Windows or an Apple JVM on OS X.
If the document is larger, or a higher resolution is used, then the
process will also use more memory. If there would be an issue with
the cleanup, then this could slow things down considerably. If this
is the case, check out if you can influence the garbage-collector
(Sun and Apple both support VM options to influence this, so IBM
probably does too).
If all else fails, then your proposed solution should also work
nicely, but it does add some overhead in maintenance, of course...
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: Performance problems when generating TIFF on IBM iSeries
Posted by Andreas Delmelle <an...@telenet.be>.
On Mar 31, 2008, at 11:04, Martin Kristensen wrote:
Hi
> I’m working on generating some PDF and TIFF files with FOP 0.94 on
> an IBM iSeries OS400 JVM 1.5. I tried ExampleFO2PDF.java which
> worked fine, except when I changed the output type to TIFF, the
> execution time went from a few seconds to more than a minute. I
> also tried PNG, which was just as slow, so it’s apparently
> bitmapped graphics in general that suffers.
>
> On my Windows box TIFF is about as fast as PDF, so my first guess
> was that it might be caused by running in java.awt.headless=true
> mode on the IBM server because of lack of GUI, but setting it to
> headless on my PC doesn’t have any effect on the speed. The second
> clue was that Java’s font rendering might be the cause, since the
> execution time correlates to the number of characters in the
> picture. But at least a test of java.awt.Graphics2D.drawString
> indicates that it’s just as fast on the iSeries.
The whole Graphics2D implementation probably differs significantly in
the IBM JVM, and that is the biggest difference between PDF and TIFF/
PNG output. For the TIFF/PNG formats, FOP draws heavily on Java AWT
(= native code, platform/implementation dependent), while for PDF/PS
practically everything is handled within FOP itself.
> Another factor is the resolution, which seems to influence the
> execution time exponentially, e.g. going from 100 to 200 DPI makes
> it more than 10 times slower. Unfortunately the output has to be in
> a fairly good resolution in order to look good when it’s faxed, so
> it’s not an option to make it fast that way.
> So I wonder whether this performance issue on the OS400 JVM is a
> known problem, or if anyone have any other suggestions.
No experience with Java on iSeries over here, but I just read that
the special OS400 JVM is less performant than IBM's Standard JVM
(which is used on IBM's Linux/AIX platform), and that IBM was going
to gradually phase out the former in favor of the latter. As of i5/
OS, the standard JVM would have been added as an option (?)
Is it already an option in your environment to try to use a different
IBM JVM?
> Otherwise the solution will probably be to run the FOP
> functionality as a web service on a Windows or Linux server, but
> it’s of course better if it can all run on the iSeries.
Also, check thoroughly whether the slowdown is not created by garbage-
collection (or lack thereof). We have received a couple of reports
indicating supposed memory-leaks in FOP. As far as I recall, all
running on IBM JVM's. I never succeeded in reproducing them with a
Sun JVM on Windows or an Apple JVM on OS X.
If the document is larger, or a higher resolution is used, then the
process will also use more memory. If there would be an issue with
the cleanup, then this could slow things down considerably. If this
is the case, check out if you can influence the garbage-collector
(Sun and Apple both support VM options to influence this, so IBM
probably does too).
If all else fails, then your proposed solution should also work
nicely, but it does add some overhead in maintenance, of course...
Cheers
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org