Don't mind the delay. Too many email addresses in a futile attempt to keep one spam-clean. Apologies to Christian.

-------- Original Message --------
Subject: Re: Performance improvement in property consumption.
Date: Thu, 14 Oct 2004 08:29:24 +1000
From: Peter B. West <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>


The principles were applied in alt-design nearly two years ago now.  It
is at least good to see that someone has applied them to HEAD.

Glen Mazza wrote:
--- Finn Bock <[EMAIL PROTECTED]> wrote:

So if we did this at the FO level, in effect, we'd
have to (1) store an instance variable of every


property for each FO, given that we wouldn't know
whether the FOEventHandler's needs it beforehand,


Yes. Which is massively more efficient than storing
the exact same properties in a PropertyList.

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

+    public FOText(char[] chars, int start, int end, FONode parent) {
         endIndex = end - start; = new char[endIndex];
         System.arraycopy(chars, start, ca, 0, endIndex);
 //      System.out.println("->" + new String(ca) + "<-");
-        textInfo = ti;
+    }

+    public void bind(PropertyList pList) {
+        commonFont = pList.getFontProps();
+        commonHyphenation = pList.getHyphenationProps();
+        color = pList.get(Constants.PR_COLOR).getColorType();
+        lineHeight = pList.get(Constants.PR_LINE_HEIGHT).getSpace();
+        letterSpacing = pList.get(Constants.PR_LETTER_SPACING);
+        whiteSpaceCollapse =
+        textTransform = pList.get(Constants.PR_TEXT_TRANSFORM).getEnum();
+        wordSpacing = pList.get(Constants.PR_WORD_SPACING);
+        wrapOption = pList.get(Constants.PR_WRAP_OPTION).getEnum();
+    }

Note the combination of simple fields for whiteSpaceCollapse and more
complex structures like CommonFont.

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.

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.

Peter B. West <>

Reply via email to