Re: Performance improvement in property consumption.
[Glen] So if we did this at the FO level, in effect, we'd have to (1) store an instance variable of every valid property for each FO, given that we wouldn't know whether the FOEventHandler's needs it beforehand, and [me] Yes. Which is massively more efficient than storing the exact same properties in a PropertyList. [Glen] 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. Keep in mind that there is 2 different sets of properties: - The set of specified properties. - The relevant properties (as listed in the spec under each element). The existing PropertyList stores the specified properties in the super HashMap and has an additional cache which stores all retrieved properties. In my proposal the specified and the cached properties are still stored in the property list but only the relevant properties are retained in the fo object. 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. No, see above. 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? Speed can be improved, but at the cost of additional memory. The beauty of my proposal is that we can pick the fastest implementation of property assignment and property lookup without worrying about the memory because the property list is released. regards, finn
Re: [GUMP@brutus]: Project xml-fop (in module xml-fop) failed
Frankly, I don't know yet what's the real problem. The deprecation warning from Commons IO was to be expected and shouldn't be fixed ATM. Let's just stick to Commons IO 1.0 for now. The deprecation warning is caused by a change post 1.0. I'll have time tomorrow morning (12hours from now) to have another look. On 13.10.2004 21:16:56 Glen Mazza wrote: If I can do anything this weekend to fix this problem, please inform me what needs to be done. Is it just find the replacement library for the deprecated function below? Jeremias Maerki
Re: Performance improvement in property consumption.
--- Finn Bock [EMAIL PROTECTED] wrote: [Glen] 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. Keep in mind that there is 2 different sets of properties: - The set of specified properties. - The relevant properties (as listed in the spec under each element). The existing PropertyList stores the specified properties in the super HashMap and has an additional cache which stores all retrieved properties. Ummm...just to be very careful so I can understand what you're saying--instead of retrieved properties above, did you mean relevant properties? In my proposal the specified and the cached properties are still stored in the property list but only the relevant properties are retained in the fo object. Glen
(Welcome Back!) RE: Question concerning Xalan.
Hello Andreas,
Very happy to see you return to the list.
Greetz,
Glen
--- Andreas L. Delmelle [EMAIL PROTECTED]
wrote:
Hi,
Try:
redirect:write
select=concat('foo',position(),'.html')
...
Dunno for sure, but could even be that it needs the
curly braces for an AVT,
like so:
redirect:write select={concat('foo'...)}
One thing's for sure: ampersands definitely can't be
used for string
concatenation in XSLT.
Cheers,
Andreas
RE: Performance improvement in property consumption.
-Original Message- From: Finn Bock [mailto:[EMAIL PROTECTED] Hi there, [Glen] Why is it more efficient (I know it is, given your metrics, but want to know why)--... snip / In my proposal the specified and the cached properties are still stored in the property list but only the relevant properties are retained in the fo object. Yes, and IIJC, at the same time, you're eliminating the need for downstream property queries having to be performed through the PropertyList, so the FObj's can communicate directly (--less underlying HashMap fetches...) So roughly: a. FObj1 asks FObj2 b. FObj2 probes its property instance variable c. FObj2 responds to FObj1 instead of a. FObj1 asks its PropertyList b. PropertyList asks FObj2's PropertyList c. FObj2's PropertyList queries its HashMap d. FObj2's PropertyList responds to PropertyList e. PropertyList responds to FObj1 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. No, see above. To clarify this further: PropertyList seems to be more than simple wrapper around the individual property-bundles. It offers a functionality of its own, so needs extra space, and because it needs to be alive to be able to provide, it currently occupies this extra space longer than strictly necessary. It's not a simple data structure, it's an object in itself, occupying memory that won't be GC'ed until the parent FObj is released. What you seem to propose is: limit the functionality of the PropertyList object to the translation of the captured lists of attributes to the already instantiated FOBj's 'properties' --in the sense of instance variables--, and because storing the props in instance vars eliminates the need for inter-FObj communication through the PropertyList, it speeds up the process downstream as well... I like it :-) 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? Speed can be improved, but at the cost of additional memory. Indeed! While your approach would only affect the size of the different FObj Classes, not the instantiated FObj's themselves. The latter would only grow because they now have extra instance variables --but the balance is ultimately kept since their PropertyList had to store these anyway--, plus certain portions of occupied memory are released earlier. All the different PropertyLists' HashMaps for starters... Besides that, I kind of like the idea of the API reflecting the spec in this way. The beauty of my proposal is that we can pick the fastest implementation of property assignment and property lookup without worrying about the memory because the property list is released. Unless there's a piece of the PropertyList's functionality I'm overlooking here... i.e. Are there conceivable situations where the particular functions offered by the current PropertyList *have* to be available downstream? And where they can't be replaced by a similar addition of functionality to the FObj (--which you always have a reference to anyway)? If the answer to immediately above questions is 'No', I can dig the beauty of the approach :-) Greetz, Andreas
Re: Performance improvement in property consumption.
Keep in mind that there is 2 different sets of properties: - The set of specified properties. - The relevant properties (as listed in the spec under each element). The existing PropertyList stores the specified properties in the super HashMap and has an additional cache which stores all retrieved properties. [Glen] Ummm...just to be very careful so I can understand what you're saying--instead of retrieved properties above, did you mean relevant properties? No, the current PropertyList caches nearly all accessed properties. This was added (IIUC) to improve speed of repeated retrieval of the same property, as typically seen for inherited properties. You can find the caching in PropertyList.findProperty(). regards, finn
Re: Performance improvement in property consumption.
In my proposal the specified and the cached properties are still stored in the property list but only the relevant properties are retained in the fo object. [Andreas] Yes, and IIJC, at the same time, you're eliminating the need for downstream property queries having to be performed through the PropertyList, so the FObj's can communicate directly (--less underlying HashMap fetches...) So roughly: a. FObj1 asks FObj2 b. FObj2 probes its property instance variable c. FObj2 responds to FObj1 instead of a. FObj1 asks its PropertyList b. PropertyList asks FObj2's PropertyList c. FObj2's PropertyList queries its HashMap d. FObj2's PropertyList responds to PropertyList e. PropertyList responds to FObj1 No, at the startElement() event the property list exists for all the parent elements and they are used to answer all property queries, including the property function and inheritance. So the process is you outline above is unchanged. PS. I'm ignoring the handling of markers in my descriptions. regards, finn
Re: (Welcome Back!) RE: Question concerning Xalan.
Hear! Hear! Three cheers for Andreas!
(btw, thanks for correcting my misguided attempt at helping... I 'knew'
it wasn't correct, but I wanted to get the response in there anyway.
Maybe I should've just said this was more of an XSLT question, and
provided a link to[1] and mentioned Dave Pawson's XSL-ent--forgive the
pun!--resource[2]).
Glen couldn't've said it better! Greetz
Web Maestro Clay
[1]
http://xml.apache.org/fop/resources.html#documents
[2]
http://www.dpawson.co.uk/xsl/sect3/bk/index.html
On Oct 14, 2004, at 11:40 AM, Glen Mazza wrote:
Hello Andreas,
Very happy to see you return to the list.
Greetz,
Glen
--- Andreas L. Delmelle [EMAIL PROTECTED]
wrote:
Hi,
Try:
redirect:write
select=concat('foo',position(),'.html')
...
Dunno for sure, but could even be that it needs the
curly braces for an AVT,
like so:
redirect:write select={concat('foo'...)}
One thing's for sure: ampersands definitely can't be
used for string
concatenation in XSLT.
Cheers,
Andreas
Web Maestro Clay
--
Clay Leeds - [EMAIL PROTECTED]
Webmaster/Developer - Medata, Inc. - http://www.medata.com/
PGP Public Key: https://mail.medata.com/pgp/cleeds.asc
[Fwd: Re: Performance improvement in property consumption.]
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]
To: [EMAIL PROTECTED]
References: [EMAIL PROTECTED]
Glen,
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
valid
property for each FO, given that we wouldn't know
whether the FOEventHandler's needs it beforehand,
and
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) {
super(parent);
endIndex = end - start;
this.ca = 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 =
pList.get(Constants.PR_WHITE_SPACE_COLLAPSE).getEnum();
+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
--
Peter B. West http://cv.pbw.id.au/
Re: Performance improvement in property consumption.
Thanks for your explanation Finn. (Also thanks Peter and Andreas for taking the time to respond--I read through both your messages quite carefully as well, in order to better understand the property resolution issues involved.) I looked at the current code and the patch again, and I think I now have a better understanding of why it performs faster. Anyway, +1 for this change, except I would like to have the FONode.start() methods renamed to .startOfNode(). IMO it is a little more descriptive to newcomers to the code (even if annoying for those very familiar with the code.) Also it complements the endOfNode() method (although I admittedly renamed that from end()), and it helps with global searches/SR's, as start() may also be defined in other packages with completely different meanings. Thanks, Glen --- Finn Bock [EMAIL PROTECTED] wrote:
