On Jul 28, 2007, at 17:21, Andreas L Delmelle wrote: <snip what="proposal of a concurrent PropertyCache" />
FWIW: I just couldn't resist extending further upon the cache, and in the meantime I have locally implemented similar caching for CommonHyphenation (already proposed last week), CommonFont and KeepProperty.
For CommonFont, since font-size and font-size-adjust may require dynamic evaluation context, I split up the class internally, so CommonFont itself gets only three references: fontSize, fontSizeAdjust and a CachedCommonFont instance containing the rest of the properties. If font-size and font-size-adjust are absolute numerics, then the whole CommonFont instance is also cached in turn. If not, then a separate instance will be created, but the six member variables for the cacheable props are traded for one member reference to a cached bundle of those props, so the non-cached instances that do get created should already be a lot smaller than they are now.
For KeepProperty, the trick was to use the cache, not at creation time (since it's a compound it is currently not possible to do so: see bugzilla 41044 for the explanation), but in the getKeep() method which is used by FObj.bind() of the different FO subclasses. The scope of the non-cached KeepProperty instances is thereby limited to the PropertyList. The FOs will always get references to cached Keeps.
Those few changes should already significantly alter the looks of a dump like the one we saw last week. More Blocks, TableCells etc.
The CommonBorderPaddingBackground is still a memory eater, but I'll have to take a look at LengthRangeProperty and CondLengthProperty first for that.
Unless any objections arise, I will commit the proposed changes tomorrow evening.
Now, it's time for me to start that Wiki-page with the results of the user-poll...
Later Andreas
