Concerning markers & rebinding properties

[Andreas L Delmelle <a_...@pandora.be>]

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

Re: Concerning markers & rebinding properties

[Andreas L Delmelle <a_...@pandora.be>]

On Jun 7, 2006, at 09:42, Jeremias Maerki wrote:

> It would be interesting to know how much time is effectively lost  
> if the
> properties are re-evaluated unconditionally.

As I indicated, it may not be much. The properties package already  
contains a lot of optimizations, and I guess it depends a bit on what  
is Rule and Exception here. In the current state, a property not  
being re-evaluated is the exception to the rule. I'll have to browse  
a bit through the Rec to see whether this reflects the prescriptions...

> 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?

I've considered a few, but I think the suggested approach has the  
benefit that it allows to settle these matters gradually. I can add  
the switch now, flip it in FObj.clone(), and use it in TableCell.bind 
(). Other FOs / Properties can be altered to use it at a later time,  
or never for that matter.

I've also considered pulling the check to the properties' side --as  
in: FObj.bind() keeps making unconditional calls to PropertyList.get 
(), and the latter sorts out whether the FO was cloned.
That would expose the 'cloned' switch one way or the other --adding  
yet another public accessor is probably the easiest way to go about  
that, but I somehow don't like this (unless that access would, for  
example, come in handy for the layoutengine or other packages)


Andreas

Re: Concerning markers & rebinding properties

[Jeremias Maerki <de...@jeremias-maerki.ch>]

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