It would be interesting to know how much time is effectively lost if the properties are re-evaluated unconditionally. However, I agree with you that it is certainly possible to skip reevaluation for many properties. And if it's easily possible it should be done. The "cloned" indicator on the FO sounds like a pretty simple and suitable solution. Or are there better ones? Thanks for working on this, Andreas.
On 07.06.2006 00:28:45 Andreas L Delmelle wrote: > > Hi all, > > Sorry for the long post, but looking into fixing bug 39560, I ran > into an obstacle which made me wonder... > > Very briefly put, the obstacle was the recalculation/re-evaluation of > the properties when a FO is a descendant of a retrieved marker. > > As I have it now, the code related to keeping track of the parent's > column-index is executed only once for every TableColumn/TableCell > (instead of 'as many times as the table is retrieved through a > marker, plus one for the original node as a marker descendant') > OTOH, the related code in ColumnNumberPropertyMaker, which relies on > the above mentioned pieces of code, would get executed multiple times > for descendants of cloned tables. (via FObj.bind() -> Property.get()) > > In the case of column-number, it is self-evident that absolute/ > initial values will never change once the original fragment has been > parsed, so there is no compelling reason for re-evaluation... The > cloned instance variables suffice in this case. > I got around this by making the call Property.get(PR_COLUMN_NUMBER) > depend on whether one of the instance variables of the cell's parent > is (not) null, which makes this more of a dirty hack as a workaround > very specific to this property and the related FO. > > Now, this got me wondering whether the whole rebinding process > couldn't be made a bit more intelligent. Instead of blindly resolving > all properties a second (third/fourth...) time, would it be an > improvement if we restricted this to, say inherited properties and > expressions containing function calls that refer to inherited > property values (and what about relative numerics, percentages)? > > To fix the bug, I was just looking at ways to exclude *this* property > from being recalculated multiple times. If there are other such > properties, then generalizing this approach could prove to be > beneficial since in the general case, we have no idea of the > complexity of the calculation. > > Note that the reverse might also be applicable: there are certainly > properties/expressions that we don't want to be evaluated at parse > time, since the results are going to be replaced anyway --avoiding > these operations could be an improvement in cases where numerous > markers are never retrieved. > > Not sure if it would mean much, but every little bit helps -- > especially if efficiency on arbitrary document sizes and structures > is a long-term goal-- so I am going to look into generalizing this. I > was thinking in the direction of adding a boolean member to FObj that > is switched when the FO is cloned. The bind() method can then be > split up into two different blocks, one for the original context -- > marker-- and one for the retrieved-marker context... as such, every > FObj or clone can decide for itself which properties need to be re- > bound from the stored propertylist. > > In the meantime, if anyone immediately sees other properties that > could benefit from this, or has neat ideas related to these matters, > feel free to share your thoughts. > > Later, > > Andreas Jeremias Maerki
