Savino, Matt C wrote:
Below is the log output for a slightly larger (66 page) report...
Reports are the root of all evil, oh well.
Your small attachment expands to an impressive 4MB file, which
contains a single table with roughly 30'000 cells. It ultimately run
out of memory around page 4 on my JDK 1.3.1 -Xmx64M on WinNT. The FO
tree for the file soaks up a good chunk of the allocated memory,
according to Jochen Wiedmann's Dr.Mem memory profiler:
bytes class
4440832 org.apache.fop.fo.flow.Block
4376280 org.apache.fop.fo.flow.TableCell
3964032 org.apache.fop.fo.PropertyList
2973024 org.apache.fop.fo.PropertyManager
2355840 org.apache.fop.fo.FOText
703200 org.apache.fop.fo.LengthProperty
468640 org.apache.fop.datatypes.FixedLength
163296 org.apache.fop.datatypes.KeepValue
438912 org.apache.fop.fo.flow.TableRow
81024 org.apache.fop.datatypes.Keep
81024 org.apache.fop.fo.KeepProperty
54432 org.apache.fop.fo.flow.TableRow$CellArray
--------
20100536 bytes
Another 18MB of java base objects like HashMap also contribute quite a
bit. This means that memory is already pretty tight before the layout
process even starts. I also the repeated font-size="8pt" and
text-align="start" causes some bloat, and deleting them reduced the
overall number of created objects by 10%. However, the effect on run
time was neglible.
Increasing the mx setting resulted in memory thrashing :-/.
A closer look at the memory profiler statistics showed that all the
layout data associated with table cells still hung around in memory at
the time memory runs out. Digging further this turned out to be caused
by table objects clinging to their layout data indefinitely. That's
bad. I put in a small hack, using the area's back pointer to release
the data for Table, AbstractTableBody, TableRow and TableCell after
rendering. This allowed me to render the file, albeit slowly due to
frequent GC. Unfortunately I'm reluctant to commit the change because
it is likely to break some things, in particular putting IDs on a
table will cause trouble in certain situations. This could probably
be fixed too, but the more the scope of the code change is broadened
the more testing would be necessary before the next release.
Conclusion: don't use tables, as they lock up a lot of memory until
the page sequence ends. If you have to use tables, use short page
sequences.
Some additional notes: the most objects created in total were of class
String (3'738'853), which is no surprise, followed by java.lang.Object
(571'663), ArrayList (389'319), HashMap$Entry(278'527) and HashMap
(122'702), which *is* a bit of a surprise. I guess the j.l.Object
counts the various arrays. Hashmap entries, lists and the objects
tended to be fairly persistent, with more than 100'000 lists and
objects as well as 135'000 hashmap entries still being referenced at
the end of the run. The hashmaps itself are less likely to be kept,
only 7'500 out of a total of 122'000 have been left. This means the
persistently referenced hashmaps keep an average of 13 entries, while
the overall average is 4.7 entries per hash map. A few maps with lots
of entries, like the ones holding the mapping from element names to
element factories may account for much of the difference. OTOH the low
overall average indicates that many of the hashmaps stay empty, there
ought to be quite some potential for optimization. I suspect many of
the lists stay empty too. Does anybody have ideas or knowledge of
tools which allow more detailed investigations of this kind of issues?
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
