Re: FO Properties and memory usage
On Nov 23, 2006, at 16:59, [EMAIL PROTECTED] wrote: Richard, Sorry for not getting back sooner. WRT the question about code conventions: Don't really know if there are any, but I'd personally put public static inner classes before instance members. I guess I'd put them after the static member variables. Cheers, Andreas Andreas L Delmelle writes: All the property classes are supposed to be immutable even though some of them aren't and none of them use final members. Is this all correct so far? True, and this could be much improved, I'd say... OK. I'll take a look at it. Whilst I'm at it I'll try and standardize some of the structure. What's the correct coding convention for ordering inner classes relative to members? AFAIU, way back when, the situation was far worse than it is now: Instead of having members for only the applicable properties described in the XSL-FO Rec., each FONode used to have one PropertyList as an instance member. Yuch! Seems like a fine idea. The Makers will then become responsible for checking whether an identical Property was already instantiated earlier, and create a new one only if there wasn't. Exactly, Richard
Re: FO Properties and memory usage
Andreas L Delmelle writes: > > All the property > > classes are supposed to be immutable even though some of them > > aren't and > > none of them use final members. Is this all correct so far? > > True, and this could be much improved, I'd say... OK. I'll take a look at it. Whilst I'm at it I'll try and standardize some of the structure. What's the correct coding convention for ordering inner classes relative to members? > AFAIU, way back when, the situation was far worse than it is now: > Instead of having members for only the applicable properties > described in the XSL-FO Rec., each FONode used to have one > PropertyList as an instance member. Yuch! > Seems like a fine idea. The Makers will then become responsible for > checking whether an identical Property was already instantiated > earlier, and create a new one only if there wasn't. Exactly, Richard
Re: FO Properties and memory usage
On Nov 23, 2006, at 12:14, [EMAIL PROTECTED] wrote: An excellent idea. However, before I go any further with implementing anything I'd like to make sure that I actually understand what's going on at the moment and (more importantly) what should be going on. As I understand it, objects in the fo tree describe the structure of the document and relate directly to the xsl:fo input. 100% correct. I myself am very much in favor of not having an identity relationship between the FOTree and the source document, but already perform some normalizing there (since there are possibly different FO structures, yielding the exact same result), and thus making the layoutengine's job a bit easier. But OK, that's another story: your base assumption is correct. All these objects descend from FONode and all have a number of distinct properties which relate in some way to the input document and which may or may not have some bearing on the output (e.g. aural and accessibility properties don't have any impact whilst font and text properties do). Also correct, and the set of properties for which each FO has members corresponds to the properties that are mentioned as applicable to that type of FO. All the property classes are supposed to be immutable even though some of them aren't and none of them use final members. Is this all correct so far? True, and this could be much improved, I'd say... What I'm less clear on is the use of PropertyList and PropertyMaker. AFAIU, way back when, the situation was far worse than it is now: Instead of having members for only the applicable properties described in the XSL-FO Rec., each FONode used to have one PropertyList as an instance member. PropertyLists however, require space for *all* possible properties even if they don't directly apply to the FONode (see the implementation of StaticPropertyList which allocates space for two arrays with a number of elements equal to the number of all properties; since about 70%, if not 85%, of those elements will be null anyway, it's a big waste to keep those lists alive much longer than is absolutely necessary). This was changed, and the PropertyList should currently only be available as a temporary window during FOTree building, only used for converting the Attributes into Property objects. In FONode.bind() these properties are transferred to the instance member slots. By the time layout kicks in, ideally, there should be no PropertyLists alive in the FOTree, with the exception of those lists for markers/retrieve- markers (currently the latter also means keeping a reference to parentPropertyLists, so the ideal is not yet reached). WRT the last remark: possible solution would be to create a PropertyList subtype that is able to collapse the tree of lists -- dump all available properties into its own instance member arrays-- and sever the link to the parentPropertyList. Some properties such as KeepProperty or EnumProperty have makers as static inner classes. That's the general idea. As far as I get the picture, external Makers are used when there is no compelling reason to create a whole new Property subclass (see FontSizePropertyMaker: there is no FontSizeProperty, since the LengthProperty infrastructure suffices for the rest) Don't know if you've already taken a look at org.apache.fop.fo.FOPropertyMapping. Very helpful class to see how the properties map to the Maker-types. Some properties such as SpaceProperty have both an inner static class and an external maker class. That's a bit of an exception. The external Maker descends from CorrespondingPropertyMaker, and seems to be used only for computing the space-* properties from the corresponding margin-* properties. The internal Maker descends from CompoundPropertyMaker and is responsible for creating the space-* properties themselves (from scratch). Some properties such as PercentLength don't seem to have any makers at all. Why? Good question. Best explanation I can think of is that PercentLength simply relies on LengthProperty.Maker. Apparently, there was no need to override the Maker as well... It occurs to me that the best strategy for handling these would be to turn all Makers into singletons and use use them as flyweight factories, introducing a new factory for the Common* property classes. What do you think? Seems like a fine idea. The Makers will then become responsible for checking whether an identical Property was already instantiated earlier, and create a new one only if there wasn't. As for the Common* property classes, I guess it would then become possible to replace all the currently unused bundles --such as for the CommonAural properties, that would be identical for a very large number of FOs-- with one instance, shared by the different FOs. Would already make a neat difference, I think... Cheers, Andreas
Re: FO Properties and memory usage
Andreas L Delmelle writes: > OTOH, if you feel like investigating further, I personally would be > very interested to see if the properties implementation cannot be > optimized in other ways than simply removing them as members from the > FOs. > > I recently mentioned the idea of flyweights. An excellent idea. However, before I go any further with implementing anything I'd like to make sure that I actually understand what's going on at the moment and (more importantly) what should be going on. As I understand it, objects in the fo tree describe the structure of the document and relate directly to the xsl:fo input. All these objects descend from FONode and all have a number of distinct properties which relate in some way to the input document and which may or may not have some bearing on the output (e.g. aural and accessibility properties don't have any impact whilst font and text properties do). All the property classes are supposed to be immutable even though some of them aren't and none of them use final members. Is this all correct so far? What I'm less clear on is the use of PropertyList and PropertyMaker. Some properties such as KeepProperty or EnumProperty have makers as static inner classes. Some properties such as SpaceProperty have both an inner static class and an external maker class. Some properties such as PercentLength don't seem to have any makers at all. Why? It occurs to me that the best strategy for handling these would be to turn all Makers into singletons and use use them as flyweight factories, introducing a new factory for the Common* property classes. What do you think? Richard
Re: FO Properties and memory usage
On Nov 22, 2006, at 13:30, [EMAIL PROTECTED] wrote: Hi Richard, I've been experiencing a couple of problems lately regarding speed and memory usage when generating some large fop reports (around 42MB .fo) Having run Hat on the hprof dump and taken a closer look at the code I see an awful lot of objects which don't appear to serve any useful purpose. e.g. ~38000 instances of CommonAural, CommonAccessibility, etc. which are never used. It seems like almost every class in the fo tree is storing redundant properties. Is there any reason why I shouldn't remove the worst offenders and submit the appropriate patch? Interesting info, and it somewhat confirms my suspicions... although we need to take care: just because they are currently not effectively used in the process doesn't mean that they are completely superfluous or redundant. Just because we currently don't have a renderer for which the CommonAural properties make sense, does not mean we never will incorporate such a renderer into FOP. If we ever do, those properties will have to be re-introduced anyway... OTOH, if you feel like investigating further, I personally would be very interested to see if the properties implementation cannot be optimized in other ways than simply removing them as members from the FOs. I recently mentioned the idea of flyweights. Take for example a property for 'font-size="10pt"'. In the current implementation, if this property occurs on a thousand different FOs, there will be exactly as many Property instances created for it, while this could be reduced to one. All the related FOs can then share a reference to that one single instance. We would add a little overhead, since for each property we'd need to check if an instance with the exact same property value is already present in the pool... but this small overhead would drastically reduce the memory usage IIC. Cheers, Andreas
FO Properties and memory usage
Hi, I've been experiencing a couple of problems lately regarding speed and memory usage when generating some large fop reports (around 42MB .fo) Having run Hat on the hprof dump and taken a closer look at the code I see an awful lot of objects which don't appear to serve any useful purpose. e.g. ~38000 instances of CommonAural, CommonAccessibility, etc. which are never used. It seems like almost every class in the fo tree is storing redundant properties. Is there any reason why I shouldn't remove the worst offenders and submit the appropriate patch? Regards, Richard
