What is the purpose of layout.Area.addLineagePair?

[Lloyd McKenzie/CanWest/IBM <lm...@ca.ibm.com>]

Hi everyone,

I'm going through FOP doing some playing around to see if I can reduce the
memory use/improve performance of FOP.  (I've got a document that takes
about 20 days to translate, and I'd like to speed it up a bit :>).

As part of the process, I've been looking at some of the elements that are
eating up large chunks of memory.  One of the candidates is the
"returnedBy" hashtable in layout.Area.  The only place this hashtable is
referenced is in the "addLineagePair(fObj fo, int position)" method.  This
method puts data into the hashtable.  However nothing else accesses the
hashtable.  I.e. We're putting stuff in, but never extracting it or looking
at it.

Was this added with a specific intended future use?  If so, what?  Is it
lying around as debris from a past requirement?  Does anyone remember?  If
I get back no responses, I'll toast it in my proposed
'performance-enhancement' changes.


Thanks for your help,


Lloyd

Lloyd McKenzie, P.Eng.              I/T Architect, IBM Global Services
Internet: LMCKENZI@CA.IBM.COM
PhoneMail: (780)421-5620          Internal Mail:AZ*K0R*1004 *EDM


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

Re: What is the purpose of layout.Area.addLineagePair?

[Arved Sandstrom <Ar...@chebucto.ns.ca>]

At 08:21 PM 11/3/01 -0700, Lloyd McKenzie wrote:
>I'm going through FOP doing some playing around to see if I can reduce the
>memory use/improve performance of FOP.  (I've got a document that takes
>about 20 days to translate, and I'd like to speed it up a bit :>).
>
>As part of the process, I've been looking at some of the elements that are
>eating up large chunks of memory.  One of the candidates is the
>"returnedBy" hashtable in layout.Area.  The only place this hashtable is
>referenced is in the "addLineagePair(fObj fo, int position)" method.  This
>method puts data into the hashtable.  However nothing else accesses the
>hashtable.  I.e. We're putting stuff in, but never extracting it or looking
>at it.
>
>Was this added with a specific intended future use?  If so, what?  Is it
>lying around as debris from a past requirement?  Does anyone remember?  If
>I get back no responses, I'll toast it in my proposed
>'performance-enhancement' changes.

Hi, Lloyd

Well, I remember putting it in. It's not what I would consider as "debris 
from a past requirement", not unless the 'generated-by' and 'returned-by' 
traits (see Section 6.1; also a mention in Section 4.1) are considered 
irrelevant.

These traits are the mechanism by which we can determine what FO(s) 
generated and returned any given area. At the time that I put in that code, 
I was thinking about keeps and markers and who knows what else, and there 
were definitely questions that I could see being asked of the area tree data 
structure that would require this information to be available.

We can debate the merits of how these traits get implemented, no question 
about it. Probably that implementation can be improved...normal areas, for 
example, which is most of them, have a 'returned-by' lineage of size 1, so 
the naive use of a generic Hashtable is contra-indicated.

I don't think there is any harm in taking it out, since it is not currently 
being used. I figure something like this will be added, though, _somewhere_, 
in future code. In any case, I think first-order performance-enhancements 
start with minimizing the _number_ of FOs and areas that are in memory, and 
efficiencies in the size of FO and area representations are second-order 
enhancements. In other words, I would not rely on areas being even as small 
as they are now...once we add all the information they are supposed to have, 
and support more functionality, they may get bigger.

Regards,
Arved Sandstrom



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