The approach I took was to resolve all of the properties at every node in the tree during the parsing. As the FO tree builder descends to the leaf nodes, a complete properties array is maintained at each level. Before the tree builder exits a node though, all properties not relevant to that particular node type are discarded (i.e. the property sets are "reduced") so that the maximal data arrays are short-lived. The relevant properties are maintained in sparse arrays.
There is a flaw in this approach which is exposed when markers are processed. Because marker subtrees are conceptually "re-parented" in the static-content tree of the page on which they are laid out, the properties within the marker tree cannot initially be resolved, and the properties of the static-content trees cannot be "reduced". This situation is not catered for in the existing code, but is quite easy to accommodate by not reducing the property sets of nodes in the static-content, and by slicing the marker subtrees out and storing them unresolved for later processing, including property resolution, in the context of static-content.
All of this assumes that property resolution cannot be completed independently of layout. This is a major point of difference between me and everyone else on the FOP team, but the implication is there in the Rec. if you read it carefully.
Peter
John Austin wrote:
Further to my notes on FOP performance characteristics of the PropertyList methods, it appears (afaik) that the design of this part of FOP exhibits linear tendencies.
Properties are stored in a tree where each 'level' corresponds to a formatting object (fo:block, fo:table)
which has local attributes (properties) and inherits further properties from enclosing objects. Each level's
properties are stored in a HashMap. Inheritence is modelled by pointers to the 'parent' and this appears
to be the cause of pathological performance in the findProperty() method. The step that looks at the parent pointer is equivalent to a linear search because there will be small numbers of attributes at each level and many levels to search.
It would seem to follow that performance would benefit
by specifying all properties at the innermost level. I suspect that this benefit would be limited by the additional costs of parsing additional attributes.
One could mitigate the effects by specifying most
properties at intermediate levels with long lifetimes
and possibly by limiting the number of extraneous levels. This approach might be pragmatic in some cases
but it is problematic and would not provide a long-term
solution.
I don't think the redesign of this component will be trivial as there are trade-off's in performance due to the fact that the tree could be quite deep and the highest levels won't have long lifetimes that could
benefit from more complex structures (which cost more to construct). I do think the component should be
redesigned but I don't offer a replacement as I don't
know what the future of the 0.20.5 code branch is.
-- Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
