--- Finn Bock <[EMAIL PROTECTED]> wrote: > Hi Team, > > I've put together another largish patch that changes > the way properties > and used by the FO objects, the layout managers and > the FOEventHandler > subclasses. > > > http://issues.apache.org/bugzilla/show_bug.cgi?id=31699 > > The performance increase is 42% while at the same > time using %27 less > memory.
... > All fo elements are required to > extract all the > properties that they need and to store the values as > instance fields in > the fo element. > I love the performance boost you're recording but have a philosophical issue of an "fo object needing a property"--it is really an issue of the *FOEventHandler subclass* that needs the properties--and some handlers need/implement more properties than others. 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 (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.) Another clarification needed: when would the property list's memory get released--at the PageSequence level, or as soon as the FO is finished? 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. Or, (to support inheritance) we may need to store instance variables for what may be a very unlikely event of a child needing that value. Also, are there any other options for releasing this memory that you know of? Is there someway this .bind() or other releasing of memory can be done within the FOEventHandler subclasses, or at least within LayoutManager (forgetting about RTF) instead? Not ruling this out--just want to be the devil's advocate here. Thanks, Glen
