Re: The effect of the property cache (or: playing around with a new toy)

[Andreas L Delmelle]

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?

Strange results for TableColumn, though, or are those 14000 instances  
normal given the input (lots of smaller nested tables)?

<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. :-)

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...


Cheers

Andreas