Looks like I really put my foot into it this time ;-)
What makes you say that?
I have repeated the measurements I did yesterday and I
think that it is a pretty reasonable conclusion that a
lot of resources are consumed by FOP in its rather
Byzantine property management code.
I just spent a while trying to understand PropertyList and PropertyListBuilder and found out that I need to understand Property and Property.Maker as well. I think I am going to have to help with this part of the project but it is going to take a while.
I offered (off-line) to look merging the Alt-Design code in to the main branch but I suspect that there are some different directions associated with this. Perhaps this is the reason it has not been done so far. I am still willing to work on this but I don't want to walk in to a firefight.
That way lies madness. When you look into the *actual* requirements for property processing, you may well draw the same conclusions as I did. In fact, when I got to the point of running some comparative timing tests, I had already decided that there were serious flaws in my design which I needed to address before proceeding. Some of those I have already mentioned. I will give you the benefit of my experiences off-line. You may be able to see a way to integrate the work I have done with the current directions of HEAD.
I believe the measurements I did yesterday and I feel that a bit of algorithm replacement should produce a significant improvement in the program.
The last assessment of the situation that I can recall on this list was that property handling is working satisfactorily so there is no need to pay any attention to it. Yes, really.
I would also like to suggest that anyone interested in performance look at Java Memory Profiler at http://www.khelekore.org/jmp/performance.html
I suspect there are still major memory leaks in FOP and this is one tool that will help you track them down.
Peter -- Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
