[Glen]
So if we did this at the FO level, in effect, we'd have to (1) store an instance variable of every valid property for each FO, given that we wouldn't know whether the FOEventHandler's needs it beforehand, and
[me]
Yes. Which is massively more efficient than storing
the exact same properties in a PropertyList.
[Glen]
Why is it more efficient (I know it is, given your metrics, but want to know why)--aren't you just moving the values already stored in the PropertyList into separate fields in the FO objects? Yes, you're releasing the PropertyList's memory, but the elements that the PropertyList previously stored are now stored in the FObj.
Keep in mind that there is 2 different sets of properties: - The set of specified properties. - The relevant properties (as listed in the spec under each element).
The existing PropertyList stores the specified properties in the super HashMap and has an additional cache which stores all retrieved properties.
In my proposal the specified and the cached properties are still stored in the property list but only the relevant properties are retained in the fo object.
So if PropertyList can be thought of as a C-like struct holding the values of its FObj's properties, what you're doing appears to be just taking that struct's member variables and moving them to the FObj.
No, see above.
But, obviously, given the performance/memory boost you're noting, PropertyList *can't* be regarded as a C-like struct. Why? Could PropertyList be made more efficient instead of this change--make it more like a C-like struct?
Speed can be improved, but at the cost of additional memory.
The beauty of my proposal is that we can pick the fastest implementation of property assignment and property lookup without worrying about the memory because the property list is released.
regards, finn
