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
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
[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
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
On Oct 15, 2004, at 12:05 AM, Finn Bock wrote:
snip
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
Clay Leeds wrote:
snip/
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.
snip/
Chris
[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
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
[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
--- 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
-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
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
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
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
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
--- Finn Bock [EMAIL PROTECTED] wrote:
Hi Team,
I've put together another largish patch that changes
the way properties
and used by the FO objects, the layout managers and
the FOEventHandler
subclasses.
http://issues.apache.org/bugzilla/show_bug.cgi?id=31699
The performance
[Glen]
All fo elements are required to
extract all the
properties that they need and to store the values as
instance fields in
the fo element.
I love the performance boost you're recording but have
a philosophical issue of an fo object needing a
property--it is really an issue of the
--- 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
18 matches
Mail list logo
