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 "Bondi: Runar Oli Bjarnason" <ro...@bi.bondi.is> on 2000/09/21 17:55:48 UTC
Large documents
Is is possible to change the garbage collection strategy used by FOP? I
keep getting OutOfMemoryErrors when processing large .fo files (14 MB or
so).
Re: Large documents
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
At 03:55 PM 9/21/00 +0000, Bondi: Runar Oli Bjarnason wrote:
>
>Is is possible to change the garbage collection strategy used by FOP? I
>keep getting OutOfMemoryErrors when processing large .fo files (14 MB or
>so).
FOP is not really optimized in any way - yet. This is mostly deliberate: we
have a whack of stuff yet to implement and it's not the right time to do
optimizations. That being said, various spots have been pointed out where we
can assist GC and we do want to get that happening.
.fo files that start at 14 MB are going to result in a humongous DOM tree
internally, I would have to think. I wouldn't expect you to have much joy
with _any_ DOM-based processor, so the preferable strategy (processor
optimizations or not) is to help out some by looking at the source and
seeing if parts of it are not independent, and processing the FO piecewise.
I don't think this will change for a long time.
An anecdote from way back: I was processing oceanographic data sets for a
researcher as a contract programmer. The available UNIX and VAX machines
were overloaded and not overly gifted with resources, so I ended up doing
the primary processing on the latest and greatest home computer. I recall
carefully segmenting binary data, putting in error checks for off-by-one
mistakes because I was doing convolutions across segment boundaries, etc
etc. Typical size of a full data set: ~500 K. Moral of the story: how soon
we forget. :-) Or in other words, just because we have 512 MB RAM and 25 GB
of HD doesn't mean that we should squander resources. And I mean this as an
observation on everything I see happening with Java processing of XML, and
_not_ just the size of your .fo file.
Arved Sandstrom
Senior Developer
e-plicity.com (www.e-plicity.com)
Halifax, Nova Scotia
"B2B Wireless in Canada's Ocean Playground"