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
Peter B. West wrote:
Victor Mote wrote:
Yes, yes, yes. Since we are trying to eliminate the need for unnecessary
object creation, why create a MinOptMax object? Why not just return the
three resolved values in separate methods. Anything that uses the
information will have to separately
Peter B. West wrote:
Glen Mazza wrote:
--- Peter B. West [EMAIL PROTECTED] wrote:
See above. In alt.design, all compounds are
shorthands, and all
shorthands are presumed to have been resolved into
their components
during FO Tree building.
BTW, does Alt-Design already resolve
Peter B. West wrote:
If we go towards integer representation, properties in the API will
always be represented by integers. By looking at this particular
signature, we are not locking ourselves in. We can add other signatures
if the need arises, but they can be extensions of the basic call.
Victor Mote wrote:
Peter B. West wrote:
Glen Mazza wrote:
--- Peter B. West [EMAIL PROTECTED] wrote:
See above. In alt.design, all compounds are
shorthands, and all
shorthands are presumed to have been resolved into
their components
during FO Tree building.
BTW, does Alt-Design already
Victor Mote wrote:
Peter B. West wrote:
If we go towards integer representation, properties in the API will
always be represented by integers. By looking at this particular
signature, we are not locking ourselves in. We can add other signatures
if the need arises, but they can be extensions of
Victor Mote wrote:
Peter B. West wrote:
It would be really nice to have a getLeaderLength()
which returns a MinOptMax. this means the getLeaderLength()
has:
- resolve percentages and functions
- deal with the leader-length shorthand setting before this
- deal with inheritance (n/a here,
--- Peter B. West [EMAIL PROTECTED] wrote:
See above. In alt.design, all compounds are
shorthands, and all
shorthands are presumed to have been resolved into
their components
during FO Tree building.
BTW, does Alt-Design already resolve the cases where
*both* a shorthand and one of
Glen Mazza wrote:
--- Peter B. West [EMAIL PROTECTED] wrote:
See above. In alt.design, all compounds are
shorthands, and all
shorthands are presumed to have been resolved into
their components
during FO Tree building.
BTW, does Alt-Design already resolve the cases where
*both* a shorthand
Good thing I asked--I may need to do that with the
Constants interface, where the ordering is currently
alphabetical.
Glen
--- Peter B. West [EMAIL PROTECTED] wrote:
It's in the ordering of the properties. There is a
simply for loop to
process properties (attributes, in fact) defined on
On the other hand a series of smaller adjustments to the property
handling has improved the total processing time about 10%.
[Peter B. West]
That's a better time improvement than I got with alt.design. The fact
that I have extra overhead from the pull parsing may account for that.
Perhaps, but
[Glen Mazza]
Thanks, Finn and John Austin, for your efforts here.
It's a pleasure.
Victor, not to rush you, but how agreeable are you in
general on switching to integer enumerations for FOP
properties? (Given Alt-Design, Peter obviously
approves.) I checked Alt-Design's PropNames.java[1]
and
[J.Pietschmann]
[snip]
If we are at it, I'd vote for dumping generating the property
classes and check the java files into CVS.
I like the generation process as it allowed me to try out and experiment
with different optimizations. I don't think that I realisticly could
have added caching of
+1 to that, but please don't dump the original XML files
(foproperties.xml etc.) because they could come handy later.
Besides that, I can't contribute much to this discussion, but I am
confident that you guys find a good solution. The integer idea sounds
reasonable to me and I'm particularly glad
Finn Bock wrote:
I like the generation process as it allowed me to try out and experiment
with different optimizations. I don't think that I realisticly could
have added caching of compound properties or changed the abs2rel/rel2abs
code if I had to change the Maker classes manually.
If its
-1. I'd like to hold off on this, at least until I
can gain a better understanding of the autogenerated
code. I may still to the same conclusion as the other
committers, but Finn's endorsement of the XSLT--as
well as the long work of those like Keiron who have
worked with the XSLT
I haven't looked at the XSLT code but I have a question
in my mind that I need to answer about it.
I wonder what it is that is being generated and what were
the design alternatives to the codegen implementation.
One question that popped in to my head was:
Is there 'missing polymorphism' here ?
Glen Mazza wrote:
-1. I'd like to hold off on this, at least until I
can gain a better understanding of the autogenerated
code. I may still to the same conclusion as the other
committers, but Finn's endorsement of the XSLT--as
well as the long work of those like Keiron who have
worked with the
I like the generation process as it allowed me to try out and
experiment with different optimizations. I don't think that I
realisticly could have added caching of compound properties or changed
the abs2rel/rel2abs code if I had to change the Maker classes manually.
[J.Pietschmann]
If its
Glen Mazza wrote:
Thanks, Finn and John Austin, for your efforts here.
Yes, and Peter, too.
Victor, not to rush you, but how agreeable are you in
general on switching to integer enumerations for FOP
properties? (Given Alt-Design, Peter obviously
approves.) I checked Alt-Design's
Peter B. West wrote:
It would be really nice to have a getLeaderLength()
which returns a MinOptMax. this means the getLeaderLength()
has:
- resolve percentages and functions
- deal with the leader-length shorthand setting before this
- deal with inheritance (n/a here, fortunately)
J.Pietschmann wrote:
If we are at it, I'd vote for dumping generating the property
classes and check the java files into CVS.
+1. I have noted Finn's and Glen's subsequent objections, and Joerg's
subsequent comments. I agree that the general need for that level of
flexibility has passed, and
Thanks, Finn and John Austin, for your efforts here.
Victor, not to rush you, but how agreeable are you in
general on switching to integer enumerations for FOP
properties? (Given Alt-Design, Peter obviously
approves.) I checked Alt-Design's PropNames.java[1]
and liked what I saw. It doesn't
Glen Mazza wrote:
Victor, not to rush you, but how agreeable are you in
general on switching to integer enumerations for FOP
properties? (Given Alt-Design, Peter obviously
approves.) I checked Alt-Design's PropNames.java[1]
and liked what I saw. It doesn't necessarily have to
be that particular
Finn Bock wrote:
Hi,
Inspired by the recent talk about optimizations, I have tried to look
for low hanging fruits that can speed up FOP, and as I expected I did
not find any silver bullets.
On the other hand a series of smaller adjustments to the property
handling has improved the total
Glen Mazza wrote:
Thanks, Finn and John Austin, for your efforts here.
Victor, not to rush you, but how agreeable are you in
general on switching to integer enumerations for FOP
properties? (Given Alt-Design, Peter obviously
approves.) I checked Alt-Design's PropNames.java[1]
and liked what I
J.Pietschmann wrote:
Glen Mazza wrote:
Victor, not to rush you, but how agreeable are you in
general on switching to integer enumerations for FOP
properties? (Given Alt-Design, Peter obviously
approves.) I checked Alt-Design's PropNames.java[1]
and liked what I saw. It doesn't necessarily have
P.S: I am willing to apply the code changes to my version
of fop(0.20.4), test it and submit the results on my large
fo files.
-Original Message-
From: Martin Poeschl [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 17, 2002 11:48 PM
To: [EMAIL PROTECTED]
Subject: Re: Performance tuning
Hello dear Venu,
Am Donnerstag, 24. Oktober 2002 20:28 schrieb Venu Reddy:
Hi,
What is the current status of this performance tuning.
Have the code changes been submitted and performance benefits
verified. I really could use some speed improvements with fop,
I have some very large reports
willing to apply the code changes to my version
of fop(0.20.4), test it and submit the results on my large
fo files.
-Original Message-
From: Martin Poeschl [mailto:mpoeschl;marmot.at]
Sent: Thursday, October 17, 2002 11:48 PM
To: [EMAIL PROTECTED]
Subject: Re: Performance tuning.
Henrik
Henrik Olsson wrote:
Hi.
I have runned several performance tests on the FOP and and I have found
out several bottle necks (especially in the PropertyListBuilder).
Most things is about reducing gc and some others about not so well written
code.
The result of this tunings gives me a speed of 3
Hi Henrik
I have started the task to create diffs.
Great.
But it makes it a bit complecated since there are about 10 diffrent things
i have done to the code and some things affects more then 20 source files.
So the question are: Do You want all the changes in one bunch or them
diffrent groups that belongs together?
Henrik
Jeremias Maerki [EMAIL PROTECTED]
2002-10-17 10:56
Please respond to fop-dev
To:[EMAIL PROTECTED]
cc:
Subject:Re: Performance tuning.
Henrik,
that sounds very interesting. Normal procedures for sending changes
Hi Henrik,
whatever the FOP-developers say, I'd like
totry andimplement your improvements in the project I'm working on.
3 times as fast, it's a dream come true!
Here's my address: [EMAIL PROTECTED]
Cheers
Guy
- Original Message -
From:
Henrik Olsson
To: [EMAIL PROTECTED]
Henrik,
that sounds very interesting. Normal procedures for sending changes is
to create a unified CVS diff file. You'll find some instructions
following the URL below:
http://xml.apache.org/source.html
It's best if you post the two diff files (against the maintenance branch
and the main
- Original Message -
From: Rhett Aultman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, July 19, 2002 5:26 PM
Subject: RE: Performance Analysis
If you're really concerned about finding the source of the memory drain,
I really have to :-)
Yyou may want to run the JVM
If you're really concerned about finding the source of the memory drain,
I really have to :-)
you may want to run the JVM with a JVMPI memory profiling agent running.
jProf is a pretty good one. If you do a Google search for jProf,
you'll find it, and if you need help using it, I'm
:[EMAIL PROTECTED]]
Sent: Mon 7/22/2002 10:40 AM
To: [EMAIL PROTECTED]
Cc:
Subject: RE: Performance Analysis
If you're really concerned about finding the source of the memory drain,
I really have
Hi Guilbert,
very interesting. If you're experiencing that FOP runs faster on a
NT-machine than on a UNIX machine then we are experiencing the same here.
The same page on my NT machine takes 1 sec whereas on the UNIX machine it
takes 10 seconds.
So far I assumed it's just a load problem of
I got much better performance on a PC running NT as compared to
Linux running on a much better machine. I was able to
get better performance on Linux using IBM's java engine
as opposed to Sun's engine.
Hope this helps.
Venu Reddy.
-Original Message-
From: GUILBERT Nicolas SIReS
Java performance has never been the same on Unix or NT. It depends on the
JVM you are using.
There have been several comparison of JVM on various OS. I don't remember
where it was nor who did it but IBM was a good choice under UNIX systems.
Hope it helps
Cyril
At 18:02 18/12/2001 +0100, you
]]
Sent: Tuesday, December 18, 2001 9:03 AM
To: [EMAIL PROTECTED]
Subject: Re: Performance difference between Unix and PC
Hi Guilbert,
very interesting. If you're experiencing that FOP runs faster on a
NT-machine than on a UNIX machine then we are experiencing
the same here.
The same page
I run
complex table stuff on Linux with FOP pretty consistently, and have not
experienced the slow-downs you mention. Are you running under Linux with a
decent amount of memory?
jw
-Original
Message-
From: Alenka Skrbinek
[mailto:[EMAIL PROTECTED]]
Sent: Thursday, October
Just in case anyone is interested, see this benchmarking from an earlier
post. I still haven't figured out what causes the serious degradation on
Unix with two or more concurrent reports. But I did find out it only
occurs when running FOP on a servlet inside Weblogic! Two separate Java
processes
I had
better performance using IBM's jre/java as opposed to Sun's version - on
Linux.
Venu
Reddy
-Original Message-From: Alenka Skrbinek
[mailto:[EMAIL PROTECTED]]Sent: Wednesday, October 17, 2001
10:29 PMTo: [EMAIL PROTECTED]Subject:
Performance
I have
Hello Joerg
FOP appears to be unable to split table cells, probably because it
requires the content of a table cell wrapped in a single fo:block
(some comments from the developers?)
FOP does split table cells. My experience is that this happens more than I
want it to be happen. For example
At 06:08 PM 10/1/01 +0900, you wrote:
As Keiron said that performance increased with just using HashMap
instead of Hashtable. How about using ArrayList instead of Vector? Well,
it depends on how much Vector is used in FOP.
Another thought is the way the FO tree and area trees are implemented.
So in conclusion I think there is a general consensus (vote) to move to
java 1.2.
I will commit what I have so far for the next release.
For java 1.1 users:
Sorry but I think it is better to do it this way. To run with java 1.1 you
could use the collections.jar and change the import statements.
Dear FOP developers,
I'm not a committer (I've sent few patches, though :), so I don't get a
official vote, but as the member of the X-Smiles project, I would really
like to see continued support for Java 1.1.
One of our target platforms is Open Source Java platform Kaffe, which is
roughly Java
So the question is: can we drop java 1.1 support and use better data
structures?
+1 for this:
-even switching to a 1.2 JVM (+hotspot) without code changes often brings big
performance improvements compared to 1.1, so IMHO forcing users to 1.2 is a
good thing for FOP in general
-the
Hey Keiron:
If you're trying to build a consensus on this issue, I'd certainly vote for
dropping 1.1 support here -- especially as FOP moves forward with new design
and layout initiatives.
jw
-Original Message-
From: Keiron Liddle [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 21,
Keiron Liddle wrote:
[..]
So the question is: can we drop java 1.1 support and use better data
structures?
--- Christian Geisert [EMAIL PROTECTED] wrote:
+1 (I think we should make this an official vote)
I think that FOP is not really usable in Applets which is the only sensible
PROTECTED]
Subject: Re: Performance and java 1.1
Keiron Liddle wrote:
[..]
So the question is: can we drop java 1.1 support and use better data
structures?
--- Christian Geisert [EMAIL PROTECTED] wrote:
+1 (I think we should make this an official vote)
I think that FOP is not really
Alex McLintock wrote:
[..]
PS What are the rules for an official vote. I have been told off before
for voicing my opinion about a vote in another Apache project. Basically
I was told I couldn't vote because I hadn't contributed any source.
Shockingly enough this is true for FOP too.
see
Keiron Liddle wrote:
Hi All,
I have been doing some performance testing so we can get an idea of how
things might be improving (or getting worse) with changes to the code.
[snip]
So the question is: can we drop java 1.1 support and use better data
structures?
Interesting results!
With
- what a joke)
-Original Message-
From: Karen Lease [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 21, 2001 5:19 PM
To: [EMAIL PROTECTED]
Subject: Re: Performance and java 1.1
Keiron Liddle wrote:
Hi All,
I have been doing some performance testing so we can get an idea of how
Keiron Liddle wrote:
Hi All,
.
Some recent changes have improved the times by about 1 - 2% but one
change
that I have tried has made about a 60% improvement with the threaded
test.
This is by simply using HashMap instead of Hashtable. This is very
significant for cocoon and
On 25 Jul 2001 16:44:47 +1000, Darren Munt wrote:
As an interim measure, we decided to produce the FO file separately
with another parser (I wont tell you which one, it will only make you
cross)
We'll make wild guesses and get cross anyway. You are using MSXML,
right? :) [No need to
I've noticed a bit of chat on the list the last few days concerning
performance. I'm having a few problems in that area and I wondered if anyone
had any suggestions. I have a 16 page document, consisting of text and
embedded images, which is presently taking 30 seconds to generate. I've
At 07:27 PM 7/24/01 +1000, Darren Munt wrote:
I'm aware that it is possible to compile java classes as COM components, but
even if I knew where to start on this, I'm not sure it would help much. The
cocoon approach was looking good for us, but we discovered that the version
of FOP that is
My confidence level of being able to transition FOP to COM myself is very
low. It would be really nice if someone would take this on :) Or maybe I'm
just being lazy.
You said earlier that Cocoon worked for you but you dropped it because
it used an older version of FOP. Did you look at
78 matches
Mail list logo
