DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUGĀ·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=41656>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED ANDĀ·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41656

           Summary: [PATCH] Proposal: some refactoring in the fo tree
           Product: Fop
           Version: 1.0dev
          Platform: All
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P2
         Component: fo tree
        AssignedTo: fop-dev@xmlgraphics.apache.org
        ReportedBy: [EMAIL PROTECTED]


The proposed patch refactors the fo tree in the following ways:
-> removal of the childNodes instance member in fop.fo.FObj
-> addition of a firstChild instance member in fop.fo.FObj
-> addition of a siblings instance member in fop.fo.FONode
-> addition of a FONodeIterator interface in FONode + corresponding 
implementation in FObj
-> changed implementations of FObj.addChildNode(), .removeChild() and 
.getChildNodes()

Possible benefits: 
Reduction of the number of ArrayLists used by the fo tree. 
Before the patch, for every FObj that has at least one child, an ArrayList is 
instantiated with a default 
capacity of 10 elements (a backing Object[10], effectively wasting space on 
nulls in a substantial 
amount of cases)
After the patch, every FObj has a maximum of 3 references: one first-child 
(possibly null), a preceding 
and a following sibling. If the node only has children, it will have only two 
references: one child, one 
uninitialized array of siblings.
Downside is that this means an added reference for any FONode, even FOText or a 
single child, but this 
may be negligeable, considering that most FObj subtypes in general have a quite 
a few references 
already (mostly properties).

Another upside: this refactoring made it possible to remove fo:character nodes 
during the refinement 
white-space-handling /as they were encountered/, so there was no more need to 
wait for the 
RecursiveCharIterator to go out of scope. The FObjIterator does not throw a 
ConcurrentModificationException, since there is no real backing list anymore.
More generally, while extremely dangerous if used carelessly, this does open up 
the possibility of 
starting to process the virtual list of child nodes while another thread keeps 
appending nodes to the 
end.

Since this is only a proof-of-concept, I'd appreciate any feedback, especially 
from the profiler-geeks 
out there (Richard? I'd be very interested to see how many more cells you can 
process before running 
into an OOMError...)
I'd expect it to save us 'some' heap space, no idea how much. OTOH, I'd also 
expect a slowdown --
since an add() means traversing the following-sibling axis until the last one 
is reached. I have not yet 
performed any optimizations where it comes to FOs with a lot of children. Maybe 
a solution would be to 
use an iterator for the addition, and append the new child to its previous 
element...?

In the (very) long run, parts of the layout algorithm may already be triggered 
sooner. 
For example: layoutmanager initialization, base element list generation, 
providing new pages...

This latter would, however, take quite a bit of refactoring, so don't get any 
wild ideas. ;)

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Reply via email to