Re: [Fwd: Re: Performance improvement in property consumption.]

[Finn Bock]

[Peter]
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.
[me]
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.
[Peter]
... no, the sparse arrays contain only properties relevant 
to the node itself.  If not, it's a bug.
I misremembered, my apologies for giving the impression that FAD use 
more memory. Thank you for setting me straight.

regards,
finn

Re: [Fwd: Re: Performance improvement in property consumption.]

[Peter B. West]

Peter B. West wrote:
Finn Bock wrote:
[Peter]
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.

The reason that the sparse arrays are constructed on the way back up the
tree (at END_ELEMENT) is that the properties on all of the children have
been resolved (except for markers and unresolved expressions), so there
is no need to maintain any values that will not be used on *this* node.
 This, I imagine, is the same justification as for your reductions.
Which is to say; no, the sparse arrays contain only properties relevant 
to the node itself.  If not, it's a bug.

Peter

Re: [Fwd: Re: Performance improvement in property consumption.]

[Peter B. West]

 Original Message 
Subject: Re: [Fwd: Re: Performance improvement in property consumption.]
Date: Fri, 15 Oct 2004 18:30:39 +1000
From: Peter B. West <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Finn Bock wrote:
[Peter]
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.
The reason that the sparse arrays are constructed on the way back up the
tree (at END_ELEMENT) is that the properties on all of the children have
been resolved (except for markers and unresolved expressions), so there
is no need to maintain any values that will not be used on *this* node.
 This, I imagine, is the same justification as for your reductions.
Peter
--
Peter B. West <http://cv.pbw.id.au/>

Re: [Fwd: Re: Performance improvement in property consumption.]

[Clay Leeds]

On Oct 15, 2004, at 1:02 PM, Finn Bock wrote:
[Clay]
Which of the alignment-* property is the one you're referring to that 
has been implemented?
I was just looking at them from the point of view of the property 
subsystem, where only "baseline-shift" has been implemented. I didn't 
mean to imply that it actually work all the way through layout.

regards,
finn
That's fine... I saw that, and wondered which. Thanks for letting me 
know!

Web Maestro Clay
--
Clay Leeds - <[EMAIL PROTECTED]>
Webmaster/Developer - Medata, Inc. - 
PGP Public Key: 

Re: [Fwd: Re: Performance improvement in property consumption.]

[Finn Bock]

[Clay]
Which of the alignment-* property is the one you're referring to that 
has been implemented?
I was just looking at them from the point of view of the property 
subsystem, where only "baseline-shift" has been implemented. I didn't 
mean to imply that it actually work all the way through layout.

regards,
finn

Re: [Fwd: Re: Performance improvement in property consumption.]

[Chris Bowditch]

Clay Leeds wrote:

When I look at the FOP Compliance page, I see a couple of items which 
are implemented (I assume this page is in reference to the 
0_20_2-maintain CVS branch--I am I correct in this assumption?).
Hi Clay - yes compliance page does refer to 0.20.5 functionality.

Chris

Re: [Fwd: Re: Performance improvement in property consumption.]

[Clay Leeds]

On Oct 15, 2004, at 12:05 AM, Finn Bock wrote:

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.
When I look at the FOP Compliance page, I see a couple of items which 
are implemented (I assume this page is in reference to the 
0_20_2-maintain CVS branch--I am I correct in this assumption?).

alignment-adjust - no
alignment-baseline - no
baseline-shift - partial (see * below)
* Only values "super" and "sub" have been implemented.
display-align - yes - (partial extended conformance--see ** below)
** Implemented only for table-cell and block-container.
** For table-cell, the "height" attribute must be set for the parent 
table-row; setting the height of the table or the table-cell results in 
vertical centering having no effect.

dominant-baseline - no
relative-align - yes - no
Which of the alignment-* property is the one you're referring to that 
has been implemented?

Web Maestro Clay
--
Clay Leeds - <[EMAIL PROTECTED]>
Webmaster/Developer - Medata, Inc. - 
PGP Public Key: 

Re: [Fwd: Re: Performance improvement in property consumption.]

[Finn Bock]

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?
[Peter]
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 
properties.

regards,
finn