--- Finn Bock <[EMAIL PROTECTED]> wrote: > > > 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 > > 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. 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. 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? > > (2) instead of the programmatic convenience of > > getPropString(PR_OFFICIAL_PROPERTY_NAME), we'd > have to > > remember what each of the properties are named in > the > > FO's (We can probably standardize these though.) > > I've consistly picked getOfficielPropertyName() as > the name of the > getter method. > OK--good--strike that argument then. (Although that's a lot of methods for us to have.) > > Another clarification needed: when would the > property > > list's memory get released--at the PageSequence > level, > > or as soon as the FO is finished? > > At the endElement() event. > OK, I like that--it guarantees that every node's ancestor--even FORoot is alive while that node is being processed. This is good. > > Because the values > > of some FO's properties further downstream depend > on > > an earlier FO's properties, we may not be able to > > release the memory when the earlier FO is > finished. > > If a property value is needed by a following > sibling, then it can be > found as an instance field on the fo object that > defined the property. > Yes, I see. Good. Thanks, Glen
