So if we did this at the FO level, in effect, we'd
have to (1) store an instance variable of every
property for each FO, given that we wouldn't know
whether the FOEventHandler's needs it beforehand,


Yes. Which is massively more efficient than storing
the exact same properties in a PropertyList.


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.


Reply via email to