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. -- John Austin <[EMAIL PROTECTED]> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
