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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
