On 18.07.2007 23:05:57 Andreas L Delmelle wrote:
> On Jul 18, 2007, at 22:17, Jeremias Maerki wrote:
>
> > So I wanted to play with this really great tool a little more and
> > ran a
> > big document which I knew would cause an OutOfMemoryError at 64MB heap
> > size. Here's what came out:
> <snip />
>
> Interesting figures!
> Did you have any chance to run a comparative test with say, FOP 0.93?
No, that need to wait until after my holidays.
One thing, I'm planning is to create a tool that downloads older FOP
revisions in a one-month rhythm to see how performance evolved over time.
I want to do this because I suspect we noticably lost performance
somewhere during the last 2 years. That could also involve taking memory
snapshots for each version to find out about memory development.
> Strange results for TableColumn, though, or are those 14000 instances
> normal given the input (lots of smaller nested tables)?
No, just lots of small tables (an example from Luis Ferro in 2006).
> <snip />
> > Immediately shows that Andreas' recent change (rev 554091) for
> > switching
> > off the SAX Locators can save a lot of memory.
>
> Well, that was also part of Richard Wheeldon's patch (Bugzilla 41044)
> containing the basic idea for the property cache. The patch itself
> ultimately got committed in a few parts, and very much trimmed down,
> but Richard deserves most of the credit. I only applied a razor to
> his patch. :-)
Oops. Thanks, Richard!!!
> > I remembered Andreas working on a property cache a couple of weeks
> > ago.
> > Seems to work fine on EnumProperty:
>
> This should be already the case in 0.93. I seem to remember Simon
> having applied Richard's initial patch shortly before the 0.93 release.
>
> > Look for class: .*EnumProperty.*
> > Class Name |Objects |Shallow
> > Heap |Retained Heap |Perm
> > ----------------------------------------------------------------------
> > ----------------------
> > org.apache.fop.fo.properties.EnumProperty$Maker| 94|
> > 4'512| |
> > org.apache.fop.fo.properties.EnumProperty | 182|
> > 4'368| |
> > Total of 2 entries | 276|
> > 8'880| |
> > ----------------------------------------------------------------------
> > ----------------------
> >
> > Then I noticed that NumberProperty (which uses the property cache)
> > has 98304 instances which couldn't be right. The problem: just using
> > that WeakHashMap isn't enough without the key objects implementing
> > hashCode() and equals() (see JDK javadocs).
>
> Ouch! A painful oversight on my part. Good thing you checked. :)
>
> As to the implementations, I'm wondering, since NumberProperty is
> actually only a proxy for an underlying java.lang.Number, whether it
> wouldn't be more convenient to simply reuse those:
>
> hashCode() {
> return number.hashCode();
> }
>
> equals(Object o) {
> if (o instanceof NumberProperty
> && o != null) {
> return this.number.equals(
> ((NumberProperty) o).number);
> } else {
> return false;
> }
>
> All we really need to uniquely identify a NumberProperty is the
> number-member, I think...
I dont' think that works, since Number doesn't implement hashCode(), for
example.
BTW, I don't know if we should do anything about the "specVal" member
variable in Property. I think it's mostly set to null.
Jeremias Maerki
