1) Only store the specified properties. That is what HEAD does now. 2) Put the relevant properties in a fast Property[] array and the remaining specified properties in a HashMap. For fo:root the result would be an array of size 1 for the 'media-usage' property. 3) Expect to store every valid property. For fo:root that would mean allocating an array large enough to store every defined property. This is what my patch does, and the "values" array works as the PropertyWindow.
... I'll try to come up with some numbers to see how much memory that would use/save compared to 1) and 3).
You can find the counts of relevant and valid properties for each element type here:
http://bckfnn-modules.sf.net/valid http://bckfnn-modules.sf.net/relevant
and a trace of the number of (base) properties defined at each element in the DocBook:TDG example I've been using all along.
http://bckfnn-modules.sf.net/prop-count
Adding these numbers together in a rough sort of way, I've come to this result. The number to the right is the amount of bytes it takes to store the references to the properties.
1) hashsize(specified): 713828 2) relevant * 4 + hashsize(specified) 3906168 3) valid * 4 7007052
Where hashsize is a function
cnt * (16 + 12) + int(cnt * 1.3333) * 4
that tries calculate to amount of memory consumed by each entry in a HashMap. 16 bytes is taken by each HashMap.Entry object and I estimate 12 bytes system overhead for each object. 1.3333 is the loadfactor of the HashMap.table array.
The number for 2) is most likely too high, it should only be necessary to store the non-relevant properties in the HashMap, but I don't have the count of non-relevant properties available.
The full summary can be found here: http://bckfnn-modules.sf.net/summary
occur: the number of times the element occurs in the input.
spec: the number of specified properties on all the occurrences of that
element type.
relev: the maximum number of relevant slots that can be filled on all
the occurrences of that element type.
valid: the maximum number of valid slots that can be filled on all
the occurrences of that element type.
regards, finn
