xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Finn Bock <bck...@worldonline.dk>
Subject Re: [Fwd: Re: Performance improvement in property consumption.]
Date Fri, 15 Oct 2004 07:05:07 GMT
>> Why is it more efficient (I know it is, given your
>> metrics, but want to know why)--aren't you just moving
>> the values already stored in the PropertyList into
>> separate fields in the FO objects?  Yes, you're
>> releasing the PropertyList's memory, but the elements
>> that the PropertyList previously stored are now stored
>> in the FObj. 
>> So if PropertyList can be thought of as a C-like
>> struct holding the values of its FObj's properties,
>> what you're doing appears to be just taking that
>> struct's member variables and moving them to the FObj.
>> But, obviously, given the performance/memory boost
>> you're noting, PropertyList *can't* be regarded as a
>> C-like struct.  Why?  Could PropertyList be made more
>> efficient instead of this change--make it more like a
>> C-like struct?


> It's a mixed bag, by the look of it.  From the patch, applying to FOText:
> +    // The value of properties relevant for character.
> +    private CommonFont commonFont;
> +    private CommonHyphenation commonHyphenation;
> +    private ColorType color;
> +    private Property letterSpacing;
> +    private SpaceProperty lineHeight;
> +    private int whiteSpaceCollapse;
> +    private int textTransform;
> +    private Property wordSpacing;
> +    private int wrapOption;
> +
> +    // End of property values
> Note the combination of simple fields for whiteSpaceCollapse and more
> complex structures like CommonFont.

I really like the combination of CommonXXX structures and simple fields, 
since it litterally matches the spec. Except that the spec doesn't have 
a FOText element so it is a bad example for me to use. The fields in 
FOText was taken from TextInfo and I suspect that eventually more fields 
will be needed in FOText.

In the rest of the elements, the set of fields matches the spec. The 
only exception is a bug where the some of the inline LayoutManagers uses 
"vertical-align" which is a shorthand. The layoutmanagers should instead 
use the properties that the shorthand sets: alignment-baseline, 
alignment-adjust, baseline-shift and dominant-baseline. But since only 
one of these properties has been implemented yet, I choose to keep the 
use of "vertical-align" for now.

> Alt-design just uses a sparse array, constructed at END_ELEMENT.  Space
> savings are progressively realized as the depth of the FO Tree reduces.
>  Maximum consumption occurs at the points of greatest depth of the
> tree, minima at the end of each page-sequence.

IIRC your sparse array does not just contain the relevant properties for 
an element (those listed in the spec under each fo:element), but the 
joined set of all properties relevant for all the allowed children. If 
this is correct, the sparse arrays stores more properties and uses more 
memory than my proposal does.

> Finn has gone a step further, and collapsed the property structures into
> local variables, which is good for both memory consumption and speed, at
> the cost of some more code.  IIUC.

Correct. In addition I also get a certain level of typesafeness for the 


View raw message