Finn Bock wrote:
[Peter B. West]
Alt-design (trying the hyphen for a while) takes different approaches
at different times. While building the subtree of any node, all of
the properties are maintained in a HashMap, along with a BitSet of
specified properties.
When the subtree construction is c
[Peter B. West]
Alt-design (trying the hyphen for a while) takes different approaches at
different times. While building the subtree of any node, all of the
properties are maintained in a HashMap, along with a BitSet of specified
properties.
When the subtree construction is complete, the Hash
> -Original Message-
> From: Peter B. West [mailto:[EMAIL PROTECTED]
>
> If I mentioned PropertyValue singletons, it was a slip of the fingers.
> I maintain Property singletons, which are exist solely to provide access
> to certain "static" information about individual properties.
>
Don't
[me]
1) Only store the specified properties. That is what HEAD does now.
2) Put the relevant properties in a fast Property[] array and the
remaining specified properties in a HashMap. For fo:root the result
would be an array of size 1 for the 'media-usage' property.
3) Expect to store every
Andreas L. Delmelle wrote:
Sorry for the long post... Just trying to put a few ideas together.
Alt-design (trying the hyphen for a while) takes different approaches at
different times. While building the subtree of any node, all of the
properties are maintained in a HashMap, along with a BitSet
On Tue, 2004-01-13 at 20:49, Glen Mazza wrote:
> Let's not get too certain of anything right now with
> respect to implementation--but you probably have a
> point--a huge and very repetitively formatted document
> (say, the Chicago phone book, perhaps) would have
> comparatively fewer properties wi
Let's not get too certain of anything right now with
respect to implementation--but you probably have a
point--a huge and very repetitively formatted document
(say, the Chicago phone book, perhaps) would have
comparatively fewer properties with a higher
cardinality for each.
Glen
--- "Andreas L.
gzilla/show_bug.cgi?id=25480
[PATCH] Experimental performance improvements.
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RE
> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
>
> OK--this may also be overkill then. Thank you for the
> analysis.
>
It will prove useful, I am sure --provided we want to uphold the intention
to be able to process any size of document (from sources that may not be as
OK--this may also be overkill then. Thank you for the
analysis.
Glen
--- Finn Bock <[EMAIL PROTECTED]> wrote:
> [Glen Mazza]
>
> > This sounds like it could be an excellent idea--a
> > PropertyRepository (extending, of course, a
> > DelmelleRepository (tm) ;) ) could be a very
> useful
> > tool
[Glen Mazza]
This sounds like it could be an excellent idea--a
PropertyRepository (extending, of course, a
DelmelleRepository (tm) ;) ) could be a very useful
tool for FO Tree Building. Prior to creating any
Property instance for any FO's array, we send the
specs of the needed property to the
Pro
Sorry for the long post... Just trying to put a few ideas together.
> From: Finn Bock [mailto:[EMAIL PROTECTED]
>
> Pardon me for repeating what might be obvious,
Well, it wasn't to me, so... thanks in advance
> but I'll like to take
> a look at what information we want to store at each FObj.
--- "Andreas L. Delmelle" <[EMAIL PROTECTED]>
wrote:
> What I'm very concerned about, for example, are
> cases like tables, where it
> would be quite awkward to have the TableCell FObj's
> reference their own copy
> of a Property instance
To put it more precisely, the individual Properties of
an F
--- Finn Bock <[EMAIL PROTECTED]> wrote:
> > I.e., for all those references to the 'foo'
> property
> > instance for the children of an FO where that
> value
> > would be inherited, we don't have to create a new
> > Property instance, just a reference to the
> inherited
> > instance.
>
> Right, th
Finn Bock wrote:
[Glen]
One thing I'm missing here, for Finn's design below:
values[0] = null // always null.
values[1] = reference to a 'foo' Property instance
values[2] = reference to a 'baz' Property instance
Can't we just have, say, values[1] refer to the
parent's Property instance in cases w
[Glen]
One thing I'm missing here, for Finn's design below:
values[0] = null // always null.
values[1] = reference to a 'foo' Property instance
values[2] = reference to a 'baz' Property instance
Can't we just have, say, values[1] refer to the
parent's Property instance in cases where inheritance
> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
>
> One thing I'm missing here, for Finn's design below:
>
> values[0] = null // always null.
> values[1] = reference to a 'foo' Property instance
> values[2] = reference to a 'baz' Property instance
>
> Can't we just have,
--- "Andreas L. Delmelle" <[EMAIL PROTECTED]>
wrote:
> > -Original Message-
> > From: Finn Bock [mailto:[EMAIL PROTECTED]
> >
> > > [Andreas L. Delmelle]
> > > In this case, however, I think you
> > > can't fully 'push' these onto the descendants,
> as this would
> > > lead to absurd storag
> -Original Message-
> From: Finn Bock [mailto:[EMAIL PROTECTED]
>
> > [Andreas L. Delmelle]
> > In this case, however, I think you
> > can't fully 'push' these onto the descendants, as this would
> > lead to absurd storage-reqs for quite average-sized documents.
>
> > OTOH, the inherited p
[Glen Mazza]
... what's your opinion on switching to FO
Constants at this time? They probably will not give
us the rate of return that property constants have;
but there may be future indexing or processing
advantages with them. I'm not strong one way or the
other on them.
Since then, you have r
--- Finn Bock <[EMAIL PROTECTED]> wrote:
> > 1.) For the new PropertyList constructor (in the
> patch), you appear to be
> > duplicating the element ID argument, once as "el",
> the other time
> > as "elementId"--just to confirm, they are
> referring to the same thing (and
> > hence one of them
gzilla/show_bug.cgi?id=25480
[PATCH] Experimental performance improvements.
--- Additional Comments From [EMAIL PROTECTED] 2004-01-10 13:45 ---
Further comments and discussions here:
http://marc.theaimsgroup.com/?l=fop-dev&m=107369978306013&w=2
http://marc.theaimsgroup.co
[Glen in bugzilla]
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25480
I'm now looking at the changes to PropertySets.java (already applied) and
PropertyList.java (only partly so) and have a few questions:
1.) For the new PropertyList constructor (in the patch), you appear to be
duplicatin
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>
> --- Additional Comments From [EMAIL PROTECTED] 2004-01-10
Glen / Finn,
Hope you don't mind my interrupting here:
Particularly this point I found interesting:
> 3.) PropertySets.java defines those properti
gzilla/show_bug.cgi?id=25480
[PATCH] Experimental performance improvements.
--- Additional Comments From [EMAIL PROTECTED] 2004-01-10 01:07 ---
Finn,
I'm now looking at the changes to PropertySets.java (already applied) and
PropertyList.java (only partly so) and have a few question
gzilla/show_bug.cgi?id=25480
[PATCH] Experimental performance improvements.
--- Additional Comments From [EMAIL PROTECTED] 2003-12-24 00:08 ---
"It does not get filled at all.
It is there to support an AFAICT unused feature in the foproperties.xml file
which makes it possible to spec
gzilla/show_bug.cgi?id=25480
[PATCH] Experimental performance improvements.
--- Additional Comments From [EMAIL PROTECTED] 2003-12-23 03:39 ---
Finn,
Oops, sorry--My recent check-in of property-sets.xsl--I forgot to give you
credit for that work. It was basically a renaming o
gzilla/show_bug.cgi?id=25480
[PATCH] Experimental performance improvements.
--- Additional Comments From [EMAIL PROTECTED] 2003-12-22 22:18 ---
It does not get filled at all.
It is there to support an AFAICT unused feature in the foproperties.xml file
which makes it possible to specify s
gzilla/show_bug.cgi?id=25480
[PATCH] Experimental performance improvements.
--- Additional Comments From [EMAIL PROTECTED] 2003-12-22 22:01 ---
Finn,
Question on the FOPropertyMapping.java class--from your changes, it is
dutifully filling up the s_htGeneric (property) HashMap from
gzilla/show_bug.cgi?id=25480
[PATCH] Experimental performance improvements.
--- Additional Comments From [EMAIL PROTECTED] 2003-12-16 12:14 ---
Excellent...Thanks for the explanation! I'll look over it tonight.
Glen
gzilla/show_bug.cgi?id=25480
[PATCH] Experimental performance improvements.
--- Additional Comments From [EMAIL PROTECTED] 2003-12-16 08:15 ---
The instances of java.util.BitSet that are created for each fo:element in
PropSets are only used for collecting the properties of that element a
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:
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
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 ca
Victor Mote wrote:
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 s
gzilla/show_bug.cgi?id=25480
[PATCH] Experimental performance improvements.
--- Additional Comments From [EMAIL PROTECTED] 2003-12-15 21:59 ---
Finn,
Thanks for your explanation.
More questions--I've just generated the PropSets.java, but am not sure what
this is needed for.
1.) As
--- Victor Mote <[EMAIL PROTECTED]> wrote:
> The previous posting seems to indicate that the
> properties have been
> decomposed, the chronologically latter posting seems
> to indicate that the
> shorthand retains its shorthand character.
I think Peter and I were talking about inner-to-FO
propert
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, do
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 sepa
gzilla/show_bug.cgi?id=25480
[PATCH] Experimental performance improvements.
--- Additional Comments From [EMAIL PROTECTED] 2003-12-15 06:58 ---
The compound properties are shifted so that both base and compound can be
stored into a single int. In PropertyList there are several cases whe
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) def
gzilla/show_bug.cgi?id=25480
[PATCH] Experimental performance improvements.
--- Additional Comments From [EMAIL PROTECTED] 2003-12-15 01:25 ---
I brought in the Constants information for a start, and will be continuing to
analyze the rest of your patch as well as Alt-Design until we're
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 shorthan
gzilla/show_bug.cgi?id=25480
[PATCH] Experimental performance improvements.
--- Additional Comments From [EMAIL PROTECTED] 2003-12-14 23:02 ---
Finn,
The property constants file that your version will generate defines three
constants as follows:
// Masks
int COMPOUND_SHIFT = 9;
--- "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
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, fortunate
gzilla/show_bug.cgi?id=25480
[PATCH] Experimental performance improvements.
--- Additional Comments From [EMAIL PROTECTED] 2003-12-14 02:24 ---
Looking at your patch currently...
Glen
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
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, fo
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 Prop
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 commo
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 XS
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 ?
-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 files--suggests
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 commo
+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 gla
[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 com
xsl-fo DTD.
In addition to the performance improvements,
I suggested before we could have some form of
// very rough pseudocode
checkPropertySupported (int property) {
return isSupported[property];
}
That would be written like this:
boolean checkPropertySupported (int property) {
return
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 it
gzilla/show_bug.cgi?id=25480
[PATCH] Experimental performance improvements.
--- Additional Comments From [EMAIL PROTECTED] 2003-12-13 07:08 ---
Created an attachment (id=9553)
New version of src\codegen\foelements.xml
gzilla/show_bug.cgi?id=25480
[PATCH] Experimental performance improvements.
--- Additional Comments From [EMAIL PROTECTED] 2003-12-13 07:08 ---
John, The foelements.xml that maps properties to elements did not include the
shorthand properties. This is fixed now.
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
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 processi
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
esn't necessarily have to
be that particular design, just the idea of integer
constants in general.
[1]
http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-fop/src/java/org/apache/fop/fo/Attic/PropNames.java?content-type=text%2Fplain&rev=1.1.2.1
Joerg? Jeremias?
In addition to the performanc
gzilla/show_bug.cgi?id=25480
[PATCH] Experimental performance improvements.
--- Additional Comments From [EMAIL PROTECTED] 2003-12-12 20:57 ---
Created an attachment (id=9551)
Test logs test1 (without patch) and test2 (with patch) in a ZIP file (tests.zip)
gzilla/show_bug.cgi?id=25480
[PATCH] Experimental performance improvements.
--- Additional Comments From [EMAIL PROTECTED] 2003-12-12 20:54 ---
Attachment 9550 was named 'test.tar.gz' in case you can't grok it.
Use Linux tar zxf or gunzip and tar to unpack it.
I shall a
gzilla/show_bug.cgi?id=25480
[PATCH] Experimental performance improvements.
--- Additional Comments From [EMAIL PROTECTED] 2003-12-12 20:48 ---
Created an attachment (id=9550)
Log files of testing without (test1) and with (test2) proposed changes.
gzilla/show_bug.cgi?id=25480
[PATCH] Experimental performance improvements.
--- Additional Comments From [EMAIL PROTECTED] 2003-12-12 20:39 ---
I tested this in a recent copy of Fop HEAD and ran in to a couple of exceptions:
My test includes the corrections for the FNF problem I reporte
gzilla/show_bug.cgi?id=25480
[PATCH] Experimental performance improvements.
--- Additional Comments From [EMAIL PROTECTED] 2003-12-12 15:54 ---
Yes, switching to integer enums may be upcoming in the near future. FOP's Alt-
Design already relies on them--see its PropNames.java class.
Glen
gzilla/show_bug.cgi?id=25480
[PATCH] Experimental performance improvements.
--- Additional Comments From [EMAIL PROTECTED] 2003-12-12 15:35 ---
The two new files that I've attached should be called
src/codegen/foelements.xml
and
src/codegen/mkpropset.xsl
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 processing time about 10%
gzilla/show_bug.cgi?id=25480
[PATCH] Experimental performance improvements.
--- Additional Comments From [EMAIL PROTECTED] 2003-12-12 15:12 ---
Created an attachment (id=9540)
A new file to placed in src/codegen
gzilla/show_bug.cgi?id=25480
[PATCH] Experimental performance improvements.
--- Additional Comments From [EMAIL PROTECTED] 2003-12-12 15:11 ---
Created an attachment (id=9539)
A new file to placed in src/codegen
gzilla/show_bug.cgi?id=25480
[PATCH] Experimental performance improvements.
--- Additional Comments From [EMAIL PROTECTED] 2003-12-12 15:10 ---
Created an attachment (id=9538)
The patch
gzilla/show_bug.cgi?id=25480
[PATCH] Experimental performance improvements.
Summary: [PATCH] Experimental performance improvements.
Product: Fop
Version: 1.0dev
Platform: Other
OS/Version: Other
Status: NEW
Severity:
76 matches
Mail list logo
