Oleg Tkachenko wrote > It's probably not too late to consider some trivial optimization of fo > tree in redesign code. In a typical fo document probably about 30% of > elements have no children or have only one child (text node usually), so > instead of eager > protected ArrayList children = new ArrayList(); > in FObj.java we can consider lazy polymorphic member > protected Object children = null; > 1) For no chidren case it remains to be null. > 2) For 1 child case it is FONode object. > 3) For children case it is ArrayList. > This means some additional logic must be implmented at addChild() and > getChildren() methods.
I thought I posted this two weeks ago. I made some measurements with the FOP examples and a few other FO files an get roughly the following statistics: 45% no child (mostly text nodes, but also fo:page-number and fo:region-*) 40% one child (many blocks and basically all inline FOs in the examples) 10% 2-5 children >4% 6-9 children <1% more than 9 children. The FOText text node is the only subclass of FONode which is not a FObj. I considered moving the children vector to FObj and had it almost ready to commit but failed on a few issues which I think I have a solution now so that I can tackle this (in the maintenance branch) again. Constructing the children vector lazily is of course part of this. It is, however much more than just a null test in addChild(), because many FO classes access the children vector directly, every access has to be protected with a check for a null vector as well. Another thought in this regard: I was tempted to create an abstract FObjComposite which is the only one which can have children in the generic sense, and have FOs like fo:layout-master-set, fo:table and fo:page-number-citation no generic children at all (only typed children like fo:simple-page-master, fo:table-body etc. which are stored separately anyway, mostly in properly typed fields). The problem here is that this could interfere badly with extensibility. OTOH, what should be extension elements which are children of fo:layout-master-set, fo:table and fo:page-number-citation good for? I asked this already, without any response. One thing I'll do is to move the responsibility to add a FO as child from the FOTreeBuilder to the FOs itself. This cleans the odd hack in the FOTreeBuilder which adds a FO as child if it's not a fo:page-sequence, and avoids creating the children vector for the above-mentioned FOs unless an extension elements asks for being added. Regards J.Pietschmann --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
