You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Carlos Villegas <ca...@uniscope.co.jp> on 2001/10/01 11:08:33 UTC

Performance

As Keiron said that performance increased with just using HashMap 
instead of Hashtable. How about using ArrayList instead of Vector? Well, 
it depends on how much Vector is used in FOP.
Another thought is the way the FO tree and area trees are implemented. 
There will be probably some changes with the redesign. However, the 
approach taken by Xalan may also be useful in FOP. In Xalan 2, the DOM 
has been replaced by DTM (Document Table Model) which uses tables of 
integers to represent the document, reducing all comparisons (of node 
names, etc.) to integer comparisons. Of course, Xalan benefits mostly 
with the faster XPath axis iterators of this implementation which are 
not relevant to FOP. Nevetherless, if not performance, DTM or the 
appropiate for FOP offers a lot of savings on memory usage.
Just a few thoughts, it may trigger some ideas.

Carlos


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org


Re: Performance

Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
At 06:08 PM 10/1/01 +0900, you wrote:
>As Keiron said that performance increased with just using HashMap 
>instead of Hashtable. How about using ArrayList instead of Vector? Well, 
>it depends on how much Vector is used in FOP.
>Another thought is the way the FO tree and area trees are implemented. 
>There will be probably some changes with the redesign. However, the 
>approach taken by Xalan may also be useful in FOP. In Xalan 2, the DOM 
>has been replaced by DTM (Document Table Model) which uses tables of 
>integers to represent the document, reducing all comparisons (of node 
>names, etc.) to integer comparisons. Of course, Xalan benefits mostly 
>with the faster XPath axis iterators of this implementation which are 
>not relevant to FOP. Nevetherless, if not performance, DTM or the 
>appropiate for FOP offers a lot of savings on memory usage.
>Just a few thoughts, it may trigger some ideas.
>
>Carlos

Hi, Carlos

Hopefully the high-level design will identify the set of questions that we 
must pose to the FO "tree" and "area tree" structures (I quote those terms 
to indicate that they are conceptual trees, and an implementation can do 
whatever it likes). At the moment we really do not have a good handle on 
exactly what those questions are - we can all think of some of them, but we 
have no master comprehensive list that can then inform detailed design and 
implementation.

I agree with you...it's a good idea to be aware of what "sister" projects 
are doing in terms of data structures.

Regards,
Arved

Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org