You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Holger Prause <h....@gmx.net> on 2002/07/19 17:16:56 UTC
Performance Analysis
Hi,
I have the task to analyse a problem one of our customers have, he gets an
java.lang.Class OutOfMemoryError when he uses FOP embedded in an application
to produce a pdf file larger than 40 pages.
I already found some points to pay attention to
1) complexity of the xsl stylesheet for producing FO
2)complexity of the xml document for producing FO
3) implementation of the xml parser
4) implementation of the xslt engine
5)FOP version
Are there some cases to pay special attention to when FOP is used?
What takes the most memory ?
Is it rigt that for performance reasons a thread with System.gc() is always
running ?
Thank you very much,
Holger
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Performance Analysis
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Holger Prause wrote:
> First thanks for your response.Ill take a close look at the source code
> tomorrow(monday).As far as i know our customers uses a lot of images.
> Is there any limitations when fop gets probelms with memory or does it
> really depends on the programmer(If he uses byte streams, etc..)?Lets say when i
> try to generate 40 pages pdf with 2 50kb jpeg images on each page.
The images are cached, this means stored in memory, and
never released (FOP was not designed for servers). For
JPEG images as described above this means 2*50kb*40 = 4Mb
Some image formats are stored after decompression, so YMMV.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Performance Analysis
Posted by Holger Prause <h....@gmx.net>.
> Holger Prause wrote:
> > I already found some points to pay attention to
> >
> > 1) complexity of the xsl stylesheet for producing FO
> > 2)complexity of the xml document for producing FO
> > 3) implementation of the xml parser
> > 4) implementation of the xslt engine
>
> While these issues in theory could cause trouble, I have
> yet to see a real, non-newbie example where they really
> do. In general the FO formatting is the culprit.
> Especially for FOP, while it got much better from 0.19 on,
> it still isn't (and was never meant until *way* into the
> project) a highly optimized tool.
>
> > Are there some cases to pay special attention to when FOP is used?
> > What takes the most memory ?
>
> Forward references, images, FOs (esp. tables) spanning lots of
> pages, long page sequences, really large fonts, deeply nested
> inline FOs (roughly in this order).
>
First thanks for your response.Ill take a close look at the source code
tomorrow(monday).As far as i know our customers uses a lot of images.
Is there any limitations when fop gets probelms with memory or does it
really depends on the programmer(If he uses byte streams, etc..)?Lets say when i
try to generate 40 pages pdf with 2 50kb jpeg images on each page.I know there
are some fo testing suites from the w3c avaible and there are also
performance report sites on fop in the internet.
> > Is it rigt that for performance reasons a thread with System.gc() is
> always
> > running ?
> Bwahahahahahaha!
Lol, well i meant that serious..
>
> J.Pietschmann
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
>
--
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Performance Analysis
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Nicola Ken Barozzi wrote:
> Not funny... ;-)
I was reminded of Vodoo rituals... you know something
like "If a program source file is short, the program
will run faster" and using the C preprocessor for
complicated macro processing to get the source file
size down a few percent. Well, there was the guy who
refused to put in comments longer than twenty characters
because "it slows down the compiler" (at -O3, yeah!)
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Performance Analysis
Posted by Nicola Ken Barozzi <ni...@apache.org>.
J.Pietschmann wrote:
> Holger Prause wrote:
>
>> Is it rigt that for performance reasons a thread with System.gc() is
>> always
>> running ?
>
> Bwahahahahahaha!
Not so funny, we had a background thread in the Cocoon cache that did
something like this on certain rules, and we got burnt.
Not funny... ;-)
hehehe
Ok, just a bit ;-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Performance Analysis
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Holger Prause wrote:
> I already found some points to pay attention to
>
> 1) complexity of the xsl stylesheet for producing FO
> 2)complexity of the xml document for producing FO
> 3) implementation of the xml parser
> 4) implementation of the xslt engine
While these issues in theory could cause trouble, I have
yet to see a real, non-newbie example where they really
do. In general the FO formatting is the culprit.
Especially for FOP, while it got much better from 0.19 on,
it still isn't (and was never meant until *way* into the
project) a highly optimized tool.
> Are there some cases to pay special attention to when FOP is used?
> What takes the most memory ?
Forward references, images, FOs (esp. tables) spanning lots of
pages, long page sequences, really large fonts, deeply nested
inline FOs (roughly in this order).
> Is it rigt that for performance reasons a thread with System.gc() is always
> running ?
Bwahahahahahaha!
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Performance Analysis
Posted by Oleg Tkachenko <ol...@multiconn.com>.
Holger Prause wrote:
> I have the task to analyse a problem one of our customers have, he gets an
> java.lang.Class OutOfMemoryError when he uses FOP embedded in an application
> to produce a pdf file larger than 40 pages.
>
>
> I already found some points to pay attention to
>
> 1) complexity of the xsl stylesheet for producing FO
> 2)complexity of the xml document for producing FO
> 3) implementation of the xml parser
> 4) implementation of the xslt engine
> 5)FOP version
6) Images size/resolution
7) Multipage tables
8) Forward page-number-citations
9) JVM memory settings
--
Oleg Tkachenko
Multiconn International, Israel
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org