Re: [Fwd: Re: Performance improvement in property consumption.]
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 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. IIRC your sparse array does not just contain the relevant properties for an element (those listed in the spec under each fo:element), but the joined set of all properties relevant for all the allowed children. If this is correct, the sparse arrays stores more properties and uses more memory than my proposal does. The reason that the sparse arrays are constructed on the way back up the tree (at END_ELEMENT) is that the properties on all of the children have been resolved (except for markers and unresolved expressions), so there is no need to maintain any values that will not be used on *this* node. This, I imagine, is the same justification as for your reductions. Peter -- Peter B. West http://cv.pbw.id.au/
Re: [Fwd: Re: Performance improvement in property consumption.]
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 page-sequence. IIRC your sparse array does not just contain the relevant properties for an element (those listed in the spec under each fo:element), but the joined set of all properties relevant for all the allowed children. If this is correct, the sparse arrays stores more properties and uses more memory than my proposal does. The reason that the sparse arrays are constructed on the way back up the tree (at END_ELEMENT) is that the properties on all of the children have been resolved (except for markers and unresolved expressions), so there is no need to maintain any values that will not be used on *this* node. This, I imagine, is the same justification as for your reductions. Which is to say; no, the sparse arrays contain only properties relevant to the node itself. If not, it's a bug. Peter
Re: [Fwd: Re: Performance improvement in property consumption.]
[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 not just contain the relevant properties for an element (those listed in the spec under each fo:element), but the joined set of all properties relevant for all the allowed children. If this is correct, the sparse arrays stores more properties and uses more memory than my proposal does. [Peter] ... no, the sparse arrays contain only properties relevant to the node itself. If not, it's a bug. I misremembered, my apologies for giving the impression that FAD use more memory. Thank you for setting me straight. regards, finn
Re: [Fwd: Re: Performance improvement in property consumption.]
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? [Peter] 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 Note the combination of simple fields for whiteSpaceCollapse and more complex structures like CommonFont. I really like the combination of CommonXXX structures and simple fields, since it litterally matches the spec. Except that the spec doesn't have a FOText element so it is a bad example for me to use. The fields in FOText was taken from TextInfo and I suspect that eventually more fields will be needed in FOText. 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 shorthand sets: alignment-baseline, alignment-adjust, baseline-shift and dominant-baseline. But since only one of these properties has been implemented yet, I choose to keep the use of vertical-align for now. 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. IIRC your sparse array does not just contain the relevant properties for an element (those listed in the spec under each fo:element), but the joined set of all properties relevant for all the allowed children. If this is correct, the sparse arrays stores more properties and uses more memory than my proposal does. 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. Correct. In addition I also get a certain level of typesafeness for the properties. regards, finn
Re: [Fwd: Re: Performance improvement in property consumption.]
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 shorthand sets: alignment-baseline, alignment-adjust, baseline-shift and dominant-baseline. But since only one of these properties has been implemented yet, I choose to keep the use of vertical-align for now. 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?). alignment-adjust - no alignment-baseline - no baseline-shift - partial (see * below) * Only values super and sub have been implemented. display-align - yes - (partial extended conformance--see ** below) ** Implemented only for table-cell and block-container. ** For table-cell, the height attribute must be set for the parent table-row; setting the height of the table or the table-cell results in vertical centering having no effect. dominant-baseline - no relative-align - yes - no Which of the alignment-* property is the one you're referring to that has been implemented? 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
Re: [Fwd: Re: Performance improvement in property consumption.]
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
Re: [Fwd: Re: Performance improvement in property consumption.]
[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 layout. regards, finn
Re: [Fwd: Re: Performance improvement in property consumption.]
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 that it actually work all the way through layout. regards, finn That's fine... I saw that, and wondered which. Thanks for letting me know! 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
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: 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
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
[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:
Re: Performance improvement in property consumption.
--- 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 increase is 42% while at the same time using %27 less memory. ... 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 *FOEventHandler subclass* that needs the properties--and some handlers need/implement more properties than others. 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 (2) instead of the programmatic convenience of getPropString(PR_OFFICIAL_PROPERTY_NAME), we'd have to remember what each of the properties are named in the FO's (We can probably standardize these though.) Another clarification needed: when would the property list's memory get released--at the PageSequence level, or as soon as the FO is finished? Because the values of some FO's properties further downstream depend on an earlier FO's properties, we may not be able to release the memory when the earlier FO is finished. Or, (to support inheritance) we may need to store instance variables for what may be a very unlikely event of a child needing that value. Also, are there any other options for releasing this memory that you know of? Is there someway this .bind() or other releasing of memory can be done within the FOEventHandler subclasses, or at least within LayoutManager (forgetting about RTF) instead? Not ruling this out--just want to be the devil's advocate here. Thanks, Glen
Re: Performance improvement in property consumption.
[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 *FOEventHandler subclass* that needs the properties--and some handlers need/implement more properties than others. Does any event handler need more or different properties than what is defined in the spec under each fo element? Because that is the set of properties that I store in the fo objects. If further properties are needed by any property consumer, it can just be added to the fo element. An example could be text-decoration on fo:block. 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. (2) instead of the programmatic convenience of getPropString(PR_OFFICIAL_PROPERTY_NAME), we'd have to remember what each of the properties are named in the FO's (We can probably standardize these though.) I've consistly picked getOfficielPropertyName() as the name of the getter method. Another clarification needed: when would the property list's memory get released--at the PageSequence level, or as soon as the FO is finished? At the endElement() event. Because the values of some FO's properties further downstream depend on an earlier FO's properties, we may not be able to release the memory when the earlier FO is finished. If a property value is needed by a following sibling, then it can be found as an instance field on the fo object that defined the property. Or, (to support inheritance) we may need to store instance variables for what may be a very unlikely event of a child needing that value. I don't understand what you mean. All property inheritence is resolved at the time of the child startElement() event. The resolution is done using the parent propertylist while it still exists. Also, are there any other options for releasing this memory that you know of? Is there someway this .bind() or other releasing of memory can be done within the FOEventHandler subclasses, or at least within LayoutManager (forgetting about RTF) instead? I don't see any benefit at all, from such approaches. PS. The description of releasing property list only apply to normal elements. All element under fo:marker are treated differently. regards, finn
Re: Performance improvement in property consumption.
--- 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? (2) instead of the programmatic convenience of getPropString(PR_OFFICIAL_PROPERTY_NAME), we'd have to remember what each of the properties are named in the FO's (We can probably standardize these though.) I've consistly picked getOfficielPropertyName() as the name of the getter method. OK--good--strike that argument then. (Although that's a lot of methods for us to have.) Another clarification needed: when would the property list's memory get released--at the PageSequence level, or as soon as the FO is finished? At the endElement() event. OK, I like that--it guarantees that every node's ancestor--even FORoot is alive while that node is being processed. This is good. Because the values of some FO's properties further downstream depend on an earlier FO's properties, we may not be able to release the memory when the earlier FO is finished. If a property value is needed by a following sibling, then it can be found as an instance field on the fo object that defined the property. Yes, I see. Good. Thanks, Glen
RE: (Victor et al) Re: Performance improvements.
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 address the 3 pieces of data anyway, so I don't see any advantage to packaging them in an object. In fact, in alt.design, getPropertyValue(PropNames.LEADER_LENGTH_MINIMUM) etc. Speaking of the minimal API, why not PropertyValue getPropertyValue(int propertyIndex)? This is presumably defined on FONode or some such, and FONode also presumably knows how to navigate the FO tree and related Area tree in order to resolve percentages and the like. That may be OK for the internal-to-FO-Tree logic, but I don't think is suitable for the API, primarily because you are locked into one signature for all properties. 1) There may be some properties for which we want to return a non-integer value (Font object, for example). 2) There may be some properties for which we wish to pass more information. 3) You are going to have some ugly case or switch logic that has to determine which property is being dealt with. My opinion is that this is not a sound approach. Victor Mote
RE: (Victor et al) Re: Performance improvements.
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 the cases where *both* a shorthand and one of its included components are specified? I.e., (usually, I believe), disregard the shorthand value for that component and use its explicitly given value instead? It's in the ordering of the properties. There is a simply for loop to process properties (attributes, in fact) defined on an FO. The order of definition ensures the correct order of evaluation - shorthand first, then any individual properties. The same goes for corresponding properties, when I get around to doing them. Check the order of properties in PropNames.java. I don't know how to reconcile this with your previous posting: 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. 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. The critical thing here is that the API not even allow anybody to ask about shorthand or compound properties. The API should allow requests only for the decomposed properties, and the FO Tree should resolve all of this before passing a value back. Victor Mote
RE: (Victor et al) Re: Performance improvements.
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. The above call does not return an int or an Integer, but a PropertyValue. public PropertyValue getPropertyValue(int property) is, in fact, the signature from FONode.java in alt.design. OK. I'll interpret this as a firm -1 on my API proposal, which is sufficient to deep-six it. I think it will be a net benefit for the project for me to withdraw from the remainder of the Properties discussion. Victor Mote
Re: (Victor et al) Re: Performance improvements.
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 resolve the cases where *both* a shorthand and one of its included components are specified? I.e., (usually, I believe), disregard the shorthand value for that component and use its explicitly given value instead? It's in the ordering of the properties. There is a simply for loop to process properties (attributes, in fact) defined on an FO. The order of definition ensures the correct order of evaluation - shorthand first, then any individual properties. The same goes for corresponding properties, when I get around to doing them. Check the order of properties in PropNames.java. I don't know how to reconcile this with your previous posting: 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. 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. The critical thing here is that the API not even allow anybody to ask about shorthand or compound properties. The API should allow requests only for the decomposed properties, and the FO Tree should resolve all of this before passing a value back. The ordering is necessary to ensure that the FO attributes are processed in the correct sequence. When the properties on a particular node and its subtree are fully parsed, the shorthands and compounds will have been expanded, and the minimal property set for the stable FO tree is constructed. See makeSparsePropsSet() in FONode.java at http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-fop/src/java/org/apache/fop/fo/FONode.java?content-type=text%2Fplainrev=1.2.2.1 Within getPropertyValue() these situations are discriminated, according to the comments on private PropertyValue[] propertySet; When the properties for this value are still being resolved, getPropertyValue() will resolve inheritance and initial values. During this process, shorthands and compounds will be resolved. At the time the subtree of the FONode has been constructed, the property set of the node will be reduced (by makeSparsePropsSet()), and the shorthands and compounds will be eliminated. A call to getPropertyValue() specifying such a property will presently, IIRC, throw an exception. If necessary, that can be adjusted to return a NoType PropertyValue, but the assumption is that by this stage, anything calling for a resolved property will be aware of which properties are valid on the node. In either case, any other method which requests such a value is going to get short shrift. I think that covers the last couple of sentences in your comment above. Basically, shorthands, etc, get resolved and eliminated from the valid property set. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: (Victor et al) Re: Performance improvements.
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 the basic call. The above call does not return an int or an Integer, but a PropertyValue. public PropertyValue getPropertyValue(int property) is, in fact, the signature from FONode.java in alt.design. OK. I'll interpret this as a firm -1 on my API proposal, which is sufficient to deep-six it. I think it will be a net benefit for the project for me to withdraw from the remainder of the Properties discussion. Victor, I thought that my input on this question was primarily informational. If I wanted to vote -1 on your proposal, I would. I did not, and still do not, intend to vote on that proposal, because 1) my primary involvement is with alt.design, and 2) I don't understand it. (I will post again shortly on the slowness of my understanding in general.) If your proposal is deep sixed, it will be by those who are more intimately involved in HEAD, and who fully understand what you are trying to achieve. My comments about the use of integers are based entirely on my experience with alt.design, which I thought might be helpful in coming up with a modified properties handler in HEAD. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: (Victor et al) Re: Performance improvements.
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, fortunately) Or getLeaderLengthMin(), getLeaderLengthOpt(), getLeaderLengthMax(), with all values resolved. 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 address the 3 pieces of data anyway, so I don't see any advantage to packaging them in an object. In fact, in alt.design, getPropertyValue(PropNames.LEADER_LENGTH_MINIMUM) etc. Speaking of the minimal API, why not PropertyValue getPropertyValue(int propertyIndex)? This is presumably defined on FONode or some such, and FONode also presumably knows how to navigate the FO tree and related Area tree in order to resolve percentages and the like. Joerg speaking here/ One of the complications in the maintenance code is that the code in the FO layout routines had to deal with resolving percentages. OTOH, the generator is mainly so ugly because Keiron et al. tried hard to press the shorthand handling into a common scheme. There should be better solutions for either problem. Nobody but the FO Tree should ever have to think about compound or shorthand properties. AFAICT, all examples of these can be decomposed into their components. The FO Tree's API should deliver only the decomposed (i.e. lowest-common-denominator or LCD) values. And yes, definitely, percentages should be handled on the FO Tree side. Make FO Tree do all of that work. 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. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: (Victor et al) Re: Performance improvements.
--- 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 its included components are specified? I.e., (usually, I believe), disregard the shorthand value for that component and use its explicitly given value instead? Thanks, Glen __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/
Re: (Victor et al) Re: Performance improvements.
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 and one of its included components are specified? I.e., (usually, I believe), disregard the shorthand value for that component and use its explicitly given value instead? It's in the ordering of the properties. There is a simply for loop to process properties (attributes, in fact) defined on an FO. The order of definition ensures the correct order of evaluation - shorthand first, then any individual properties. The same goes for corresponding properties, when I get around to doing them. Check the order of properties in PropNames.java. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: (Victor et al) Re: Performance improvements.
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 an FO. The order of definition ensures the correct order of evaluation - shorthand first, then any individual properties. The same goes for corresponding properties, when I get around to doing them. Check the order of properties in PropNames.java. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/
Re: Performance improvements.
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 doesn't make much sense comparing 'improvement' between the two designs. Not all of my speedup comes from using integers, some came from caching the default values from compound properties and from removing a lot of StringBuffer.append calls in the way the Makers are handling corresponding properties. Neither of these two changes can apply to alt.design AFAICT, so the percent wise improvement that you found will naturally be smaller. regards, finn
Re: (Victor et al) Re: Performance improvements.
[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 liked what I saw. It doesn't necessarily have to
be that particular design, just the idea of integer
constants in general.
For inspiration you can also take a look at some of the same files that
I made:
http://bckfnn-modules.sf.net/Constants.java
http://bckfnn-modules.sf.net/FOPropertyMapping.java
http://bckfnn-modules.sf.net/PropSets.java
The PropSets.java file is created from a new .xml file that specifies
the element and property structure.
http://bckfnn-modules.sf.net/foelements.xml
Perhaps the information in PropSets.java could also be created from a
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 indices[i] != 0;
}
It appears that using int constants gives us more ways
to efficiently work with the data.
I agree.
regards,
finn
Re: (Victor et al) Re: Performance improvements.
[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 compound properties or changed the abs2rel/rel2abs code if I had to change the Maker classes manually. regards, finn
Re: (Victor et al) Re: Performance improvements.
+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 that a few new smart heads start to get active on HEAD. Thank you for your efforts! On 13.12.2003 01:34:02 J.Pietschmann wrote: If we are at it, I'd vote for dumping generating the property classes and check the java files into CVS. Jeremias Maerki (who's still looking for a way out of his current Delphi swamp)
Re: (Victor et al) Re: Performance improvements.
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 common code, that's what class hierarchies and inheritance are made for. J.Pietschmann
Re: (Victor et al) Re: Performance improvements.
-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 that there are significant time benefits to using them. (At work, I use SQL to write SQL all the time, and love the time efficiencies that result.) If we check in the Java code, then changes may end up being made to those files directly, which will result in the XSLT files becoming unregeneratable. Or, every run of the XSLT will require re-modification of the changes made manually to all the Java files--potentially dozens--100's of files. So I'm kind of leery about doing this at the moment. [Actually, I'm looking forward to studying the XSLT that generates these files--as I mentioned to Clay that CVS and Ant were two of the initial benefits you get by working on FOP, apparently being about to write Java code using XSLT is a third one...i.e., Yeehaw!, as I believe he had put it... ;)] Glen --- J.Pietschmann [EMAIL PROTECTED] wrote: 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 common code, that's what class hierarchies and inheritance are made for. J.Pietschmann __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/
Re: (Victor et al) Re: Performance improvements.
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 ? As I said, I only have the question at this time. On Sat, 2003-12-13 at 12:12, 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 XSLT files--suggests that there are significant time benefits to using them. (At work, I use SQL to write SQL all the time, and love the time efficiencies that result.) If we check in the Java code, then changes may end up being made to those files directly, which will result in the XSLT files becoming unregeneratable. Or, every run of the XSLT will require re-modification of the changes made manually to all the Java files--potentially dozens--100's of files. So I'm kind of leery about doing this at the moment. [Actually, I'm looking forward to studying the XSLT that generates these files--as I mentioned to Clay that CVS and Ant were two of the initial benefits you get by working on FOP, apparently being about to write Java code using XSLT is a third one...i.e., Yeehaw!, as I believe he had put it... ;)] Glen --- J.Pietschmann [EMAIL PROTECTED] wrote: 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 common code, that's what class hierarchies and inheritance are made for. J.Pietschmann __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ -- John Austin [EMAIL PROTECTED]
Re: (Victor et al) Re: Performance improvements.
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 XSLT files--suggests that there are significant time benefits to using them. (At work, I use SQL to write SQL all the time, and love the time efficiencies that result.) Well, the XSLT generation of the Java classes was good for bootstrap, because the properties were gained from the XML source of the spec. The FO java classes were bootstrapped this way too. This came handy while the spec was in flux and properties and elements were added and changed. Remember, FOP tracked the spec from the early development, and some bugs like the white-space-collapse peciliarities are leftovers from this phase. Unfortunately, meanwhile generating has become more of a burden, because if you look at in in detail, there are very, very few properties which are handled identically. Catering for the fine differences has led to many ugly hooks in the presumably generic code (have a look at GenericShorthandParser, which isn't generic enough to parse font shorthand properties). [Actually, I'm looking forward to studying the XSLT that generates these files--as I mentioned to Clay that CVS and Ant were two of the initial benefits you get by working on FOP, apparently being about to write Java code using XSLT is a third one...i.e., Yeehaw!, as I believe he had put it... ;)] Well, I fell for the trap too...I'm all in for code generators, and I regularly use some and write some for myself. However, code generation has to have benefits, and if I have to provide 183 choose cases for individual code for (a fixed number of) 185 items, there is no longer any reasonable benefit. A class hierarchy, and some proper abstractions should be enough to avoid code duplication. If I had time I'd even rewrite the propery code nearly from scratch, because - provide a proper property expression tree - deal with shorthands and font family selections in a less convoluted way - perhaps use a grammar driven parser for property expressions The intermingling of (improper) tokenizing, top-down parsing and error handling for property expressions as well as the improper reuse of tokenizing for shorthand parsing (despite it being a completely different grammar) was always enough to drive my blood pressure through the roof. J.Pietschmann
Re: (Victor et al) Re: Performance improvements.
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 common code, that's what class hierarchies and
inheritance are made for.
Indeed, but then I think you are talking about a cleaner rewritten
property handling class hierarchies, right?
But in what we have generated now, the similarities isn't handled by
inheritance. So there is a certain amount of repeated-but-not-equal code
in the Maker classes.
For instance, the 22 makers with isCorrespondingForced() methods,
generates this kind of code in HEAD:
public boolean isCorrespondingForced(PropertyList propertyList) {
FObj parentFO = propertyList.getParentFObj();
StringBuffer sbExpr=new StringBuffer();
sbExpr.setLength(0);
sbExpr.append(margin-);
sbExpr.append(propertyList.wmRelToAbs(PropertyList.START));
if (propertyList.getExplicit(sbExpr.toString()) != null)
return true;
return false;
}
and my optimized code looks like this:
public boolean isCorrespondingForced(PropertyList propertyList) {
FObj parentFO = propertyList.getParentFObj();
if (propertyList.getExplicit(propertyList.wmMap(
Constants.P_MARGIN_LEFT,
Constants.P_MARGIN_RIGHT,
Constants.P_MARGIN_TOP)) != null)
return true;
return false;
}
Another optimization that I would like to try out, involves creating a
copy of the PropertyList.findProperty() method in the Maker classes,
but one that doesn't call isCorrespondingForced() if the maker knows
that it always return false and doesn't call getExplicit if there isn't
any shorthands defined. Such an experiment is downright impossible if
the Maker isn't generated.
regards,
finn
RE: (Victor et al) Re: Performance improvements.
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 PropNames.java[1] and liked what I saw. It doesn't necessarily have to be that particular design, just the idea of integer constants in general. That is fine. I hope nothing I have said would be interpreted to the contrary, and I can't imagine why you might think that this proposition rushes me (were you waiting on me for something?). I have the least knowledge of or interest in the performance side. Having said that, I *very* much want us to implement a lowest-common-denominator, it-will-never-matter-what-the-guts-look-like API for the FO Tree to deliver the property values. That is totally independent of the way properties are stored and computed. Victor Mote
RE: (Victor et al) Re: Performance improvements.
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) Or getLeaderLengthMin(), getLeaderLengthOpt(), getLeaderLengthMax(), with all values resolved. 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 address the 3 pieces of data anyway, so I don't see any advantage to packaging them in an object. Joerg speaking here/ One of the complications in the maintenance code is that the code in the FO layout routines had to deal with resolving percentages. OTOH, the generator is mainly so ugly because Keiron et al. tried hard to press the shorthand handling into a common scheme. There should be better solutions for either problem. Nobody but the FO Tree should ever have to think about compound or shorthand properties. AFAICT, all examples of these can be decomposed into their components. The FO Tree's API should deliver only the decomposed (i.e. lowest-common-denominator or LCD) values. And yes, definitely, percentages should be handled on the FO Tree side. Make FO Tree do all of that work. Victor Mote
RE: (Victor et al) Re: Performance improvements.
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 that these things *should* be rewritten in a more OO way. I may be wrong, but I think most of these classes will disappear after this stuff is properly rationalized. The vast majority of the values can be reduced to primitive data types that can be stored directly in FO Object instances. I think one other advantage of the generated code was that it was easier to deal with whether a property was supported or not. However, support for properties now needs to be handled by the LayoutStrategy implementations. IOW, as far as FO Tree is concerned, it handles all objects and properties, and should remain agnostic about how that information may or may not be used. Victor Mote
(Victor et al) Re: Performance improvements.
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 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%2Fplainrev=1.1.2.1
Joerg? Jeremias?
In addition to the performance improvements,
I suggested before we could have some form of
// very rough pseudocode
checkPropertySupported (int property) {
return isSupported[property];
}
to quickly index properties supported for a particular
FO.
Also, for toString() implementations that will list
*all* the properties for a particular FO, we might be
able to have something very simple like this:
class FObj:
String toString {
String state;
for (int i; i PROPMAX; i++) {
state += getPropertyValue(i).toString() + \n;
}
return state;
}
It appears that using int constants gives us more ways
to efficiently work with the data.
Thanks,
Glen
--- Finn Bock [EMAIL PROTECTED] 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.
__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
Re: (Victor et al) Re: Performance improvements.
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 design, just the idea of integer constants in general. There are some ugly considerations. I think at the FO level properties should be prepared into redy-to-use bundles. At some point something has to deal with the oddities called compound properties. 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) One of the complications in the maintenance code is that the code in the FO layout routines had to deal with resolving percentages. OTOH, the generator is mainly so ugly because Keiron et al. tried hard to press the shorthand handling into a common scheme. There should be better solutions for either problem. If we are at it, I'd vote for dumping generating the property classes and check the java files into CVS. J.Pietschmann
Re: Performance improvements.
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 processing time about 10%. 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. - Switched from string based property names to integer enums. Most of the lookups then changed from get(font-size) to get(P_FONT_SIZE) and compound property lookup changed to get(P_SPACE_AFTER | C_OPTIMUM). - Cached the non-contextdep default compound properties in the makers. This caching is similar to what already existed for the base properties. - Calculated rel2abs and abs2rel in the property makers at codegen time to avoid string manipulation at runtime. - Changed the element lookup in ProperyListBuilder.elementTable from using string keys to using integer enums. - Copy the inherited property values from parent fo into the child fo. findProperty() is then no longer recursive. The data structure that maps properties ids to the property object is an sparse java array somewhat (AFAICT) similar to those in alt-design. The indication of whether a property is explicit set is stored in a bit array. Further optimizations: - The PropertyManager stores a lot of properties in instance fields. Perhaps the properties in the PropertyList can be removed after the PropertyManager has taken what it needs. The remaining properties could then be packed more efficiently. - The entire logic in findProperty() could be moved to the property makers. This could avoid 630.000 calls to the empty default methods in Property.Maker. A compiled version of my changes can be downloaded here: http://bckfnn-modules.sf.net/fop.jar I'm pleased to see that ideas from alt.design are making their way into the HEAD redesign. I will assist where I can. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: (Victor et al) Re: Performance improvements.va.
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 saw. It doesn'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%2Fplainrev=1.1.2.1
Joerg? Jeremias?
In addition to the performance improvements,
I suggested before we could have some form of
// very rough pseudocode
checkPropertySupported (int property) {
return isSupported[property];
}
to quickly index properties supported for a particular
FO.
Alt.design uses BitMaps for this. Finn seems to have adopted the
method. See previous references to data structures in FONode.java.
Also, for toString() implementations that will list
*all* the properties for a particular FO, we might be
able to have something very simple like this:
class FObj:
String toString {
String state;
for (int i; i PROPMAX; i++) {
state += getPropertyValue(i).toString() + \n;
}
return state;
}
It appears that using int constants gives us more ways
to efficiently work with the data.
Note that there are no compound properties in alt.design. From what I
recall of the original design, properties are subclasses of datatypes
which implement particular interfaces.In alt.design, property
classes as such only exist as singletons, and are never otherwise
instantiated. Instances of datatypes are instantiated, and associated
with properties only by the presence of the property index. I suspect,
without being able to demonstrate it, that the alt.design approach gives
greater flexibility in assigning intermediate and undetermined values to
properties.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: (Victor et al) Re: Performance improvements.
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 to be that particular design, just the idea of integer constants in general. There are some ugly considerations. I think at the FO level properties should be prepared into redy-to-use bundles. At some point something has to deal with the oddities called compound properties. They're shorthands, with some slightly different inheritance characteristics. I think Arved may have come to the same conclusion. 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) Or getLeaderLengthMin(), getLeaderLengthOpt(), getLeaderLengthMax(), with all values resolved. One of the complications in the maintenance code is that the code in the FO layout routines had to deal with resolving percentages. OTOH, the generator is mainly so ugly because Keiron et al. tried hard to press the shorthand handling into a common scheme. There should be better solutions for either problem. While I haven't done the corresponding properties for alt.design yet, shorthand and compound properties are handled, if not prettily, at least coherently. Percentages will. I think, be resolved by tightly integrating the processing of FO nodes and areas within PageSequence, so that these values are resolved as early as possible. For example, the relevant reference-area will be made available from the area construction logic to the FO tree builder for resolution of the properties at the time of parsing. In most cases, the area will be dimensioned at this time, but where not, the linkage between FO node and area will be established. If we are at it, I'd vote for dumping generating the property classes and check the java files into CVS. +1 Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
RE: Performance tuning.
Nothing is not yet submitted, due to circumstances at work. I think I can send a part of it next week that gives aboute 30% faster fop. Henrik Venu Reddy [EMAIL PROTECTED] 2002-10-24 20:28 Please respond to fop-dev To:[EMAIL PROTECTED] cc: Subject:RE: Performance tuning. 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 400/500 pages that are taking 5+ minutes to run. Thanks, Venu Reddy 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. 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 time faster than the original FOP. WOW!!! So what do I do to get the code in to the fop-project (the problems are both in the fop 0.20.4 and in the DEV 1.0). I have also figured out some more thing but they are not so general but it makes the FOP as fast as a comersial tool written in C++ (StreamServe). could you make your patched version available somewhere??? if you don't have a server, just send it to my private mail and i'll put it in my home_dir at the apache server ;-) martin Henrik. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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 400/500 pages that are taking 5+ minutes to run. I don't know wether you already discussed this: If you create indices, tocs and other page references, you might want to create them seperately and instead run fop several times on the same document (often fop is run repeatedly anyway), do it the way TeX does it. This might also speed up things a little. Anyway, I create student guides for courses here, they also tend to be big, the same size as your docs. Usually it takes about 30-90 seconds to fop them or less (Laptop, Athlon XP 1600+). Bye -- ITCQIS GmbH Christian Wolfgang Hujer Geschäftsführender Gesellschafter Telefon:+49 (0)89 27 37 04 37 Telefax:+49 (0)89 27 37 04 39 E-Mail:[EMAIL PROTECTED] WWW: http://www.itcqis.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Performance tuning.
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 400/500 pages that are taking 5+ minutes to run. Thanks, Venu Reddy 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:mpoeschl;marmot.at] Sent: Thursday, October 17, 2002 11:48 PM To: [EMAIL PROTECTED] Subject: Re: Performance tuning. 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 time faster than the original FOP. WOW!!! So what do I do to get the code in to the fop-project (the problems are both in the fop 0.20.4 and in the DEV 1.0). I have also figured out some more thing but they are not so general but it makes the FOP as fast as a comersial tool written in C++ (StreamServe). could you make your patched version available somewhere??? if you don't have a server, just send it to my private mail and i'll put it in my home_dir at the apache server ;-) martin Henrik. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Performance tuning.
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 time faster than the original FOP. WOW!!! So what do I do to get the code in to the fop-project (the problems are both in the fop 0.20.4 and in the DEV 1.0). I have also figured out some more thing but they are not so general but it makes the FOP as fast as a comersial tool written in C++ (StreamServe). could you make your patched version available somewhere??? if you don't have a server, just send it to my private mail and i'll put it in my home_dir at the apache server ;-) martin Henrik. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Performance tuning.
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 separated in 10 diffrent groups that belongs together? Have you tried to run the diff from the src directory? Then, CVS should create a diff that spans all modified files in this directory. I hope this helps. Before I became a committer I used to do the diffing in WinCVS and copy/paste the results together to a single file. But I heard that's not best practice. I hope this helps. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Performance tuning.
Hi Jeremias. I have started the task to create diffs. 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 separated in 10 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 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 branch) in a BugZilla entry, so it's not likely to get lost. One of the committers (I'll try to do it during the weekend if you can submit it it before then) will then review and apply the patch to the codebase. BugZilla is here: http://nagoya.apache.org/bugzilla/ Thanks a lot! 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 time faster than the original FOP. So what do I do to get the code in to the fop-project (the problems are both in the fop 0.20.4 and in the DEV 1.0). I have also figured out some more thing but they are not so general but it makes the FOP as fast as a comersial tool written in C++ (StreamServe). Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Performance tuning.
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] Sent: Thursday, October 17, 2002 10:30 AM Subject: Performance tuning. Hi.I have runned several performance tests on the FOP and and I have foundout several bottle necks (especially in the PropertyListBuilder).Most things is about reducing gc and some others about not so well writtencode.The result of this tunings gives me a speed of 3 time faster than theoriginal FOP.So what do I do to get the code in to the fop-project (the problems areboth in the fop 0.20.4 and in the DEV 1.0).I have also figured out some more thing but they are not so general but itmakes the FOP as fast as a comersial tool written in C++ (StreamServe).Henrik.
Re: Performance tuning.
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 branch) in a BugZilla entry, so it's not likely to get lost. One of the committers (I'll try to do it during the weekend if you can submit it it before then) will then review and apply the patch to the codebase. BugZilla is here: http://nagoya.apache.org/bugzilla/ Thanks a lot! 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 time faster than the original FOP. So what do I do to get the code in to the fop-project (the problems are both in the fop 0.20.4 and in the DEV 1.0). I have also figured out some more thing but they are not so general but it makes the FOP as fast as a comersial tool written in C++ (StreamServe). Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Performance Analysis
- 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 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 here. I've written a JVM profiling agent before, so I know my way around that block. IIRC, the heaviest drain on FOP is dealing with graphics and SVG. As for the question about keeping a thread with System.gc() running... That may help the JVM to more aggressively clean out memory, but most memory leaks in Java are caused by objects that the GC misses, either because of some unusual memory lay our or (more commonly) because a part of the program is still holding a reference to the object. It may not even be leaking memory...it could just be heavy usage. Heavy but conscientious use of memory would still cause memory to run out, and all the calls to System.gc() in the world won't keep that from happening. Aside from all of that, calling System.gc() does not guarantee that the GC will run. All it does is offer a suggestion that the GC's priority be greater for a short period of time. If you really want deterministic garbage collection, there are some JVMPI and JNI tricks that will let you get away with it, but in general, this won't really help your memory concerns. -Original Message- From: Holger Prause [mailto:[EMAIL PROTECTED]] Sent: Friday, July 19, 2002 11:17 AM To: [EMAIL PROTECTED] Subject: Performance Analysis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Performance Analysis
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 here. I've written a JVM profiling agent before, so I know my way around that block. That very nice, i could need it (Is JProf an api and u coded an profiler using that api?). I have to test it on a custom tag library - performing the xslt transformation. Can u mail the program to me ? My mail is [EMAIL PROTECTED] In the mean time i found out what takes so much memory, its a very brave way of programming (using strings as buffer instead of byte streams, etc...).As workaround i increased the heap of the vm to 256m. IIRC, the heaviest drain on FOP is dealing with graphics and SVG. Thats what all ppl told me as answer for my question what takes most memory.Ill suggest our customer to reduce the use of images. As for the question about keeping a thread with System.gc() running... That may help the JVM to more aggressively clean out memory, but most memory leaks in Java are caused by objects that the GC misses, either because of some unusual memory lay our or (more commonly) because a part of the program is still holding a reference to the object. It may not even be leaking memory...it could just be heavy usage. Heavy but conscientious use of memory would still cause memory to run out, and all the calls to System.gc() in the world won't keep that from happening. Aside from all of that, calling System.gc() does not guarantee that the GC will run. All it does is offer a suggestion that the GC's priority be greater for a short period of time. Ok good to know, but thats not very new for me.Hmm is that Thread running in fop or not ? (I suppos its not because of the funny answers i got) If you really want deterministic garbage collection, there are some JVMPI and JNI tricks that will let you get away with it, but in general, this won't really help your memory concerns. I think that will not be necessary. Thank you very much, Holger -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Performance Analysis
jProf is actually its own complete memory profiling system. It's based on the JVMPI API, much like my much simpler homebrew profiler was. jProf will give you a pretty detailed analysis of how much of the heap got used up by which types of objects, and IIRC it also gives information on method call sequences that allocated objects and so forth. It's quite expansive, and even comes with an attractive GUI frontend if you don't like looking at reports on the command line. Just do a Google search for jProf -Original Message- From: Holger Prause [mailto:[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 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 here. I've written a JVM profiling agent before, so I know my way around that block. That very nice, i could need it (Is JProf an api and u coded an profiler using that api?). I have to test it on a custom tag library - performing the xslt transformation. Can u mail the program to me ? My mail is [EMAIL PROTECTED] In the mean time i found out what takes so much memory, its a very brave way of programming (using strings as buffer instead of byte streams, etc...).As workaround i increased the heap of the vm to 256m. IIRC, the heaviest drain on FOP is dealing with graphics and SVG. Thats what all ppl told me as answer for my question what takes most memory.Ill suggest our customer to reduce the use of images. As for the question about keeping a thread with System.gc() running... That may help the JVM to more aggressively clean out memory, but most memory leaks in Java are caused by objects that the GC misses, either because of some unusual memory lay our or (more commonly) because a part of the program is still holding a reference to the object. It may not even be leaking memory...it could just be heavy usage. Heavy but conscientious use of memory would still cause memory to run out, and all the calls to System.gc() in the world won't keep that from happening. Aside from all of that, calling System.gc() does not guarantee that the GC will run. All it does is offer a suggestion that the GC's priority be greater for a short period of time. Ok good to know, but thats not very new for me.Hmm is that Thread running in fop or not ? (I suppos its not because of the funny answers i got) If you really want deterministic garbage collection, there are some JVMPI and JNI tricks that will let you get away with it, but in general, this won't really help your memory concerns. I think that will not be necessary. Thank you very much, Holger -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] winmail.dat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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 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 this UNIX machineas it has to handle the load of 30 developers, everybody with own processes of our backend system which is very performance consuming. But would be interesting to know wether this is the case or if FOP is really slower on UNIX. Does anybody know? Jens GUILBERT Nicolas SIReS schrieb: Who can explain the huge performance difference we experience between using FOP on a NT server or a PC on one side, or on a unix platform on the other side. Is it normal ? Is FOP built to run on PC or NT ? As it is a java library, it is supposed to work on all platform ? Thanks. Nicolas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Performance difference between Unix and PC
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 [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 18, 2001 7:16 AM To: [EMAIL PROTECTED] Subject: Performance difference between Unix and PC Who can explain the huge performance difference we experience between using FOP on a NT server or a PC on one side, or on a unix platform on the other side. Is it normal ? Is FOP built to run on PC or NT ? As it is a java library, it is supposed to work on all platform ? Thanks. Nicolas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Performance difference between Unix and PC
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 wrote: 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 this UNIX machineas it has to handle the load of 30 developers, everybody with own processes of our backend system which is very performance consuming. But would be interesting to know wether this is the case or if FOP is really slower on UNIX. Does anybody know? Jens GUILBERT Nicolas SIReS schrieb: Who can explain the huge performance difference we experience between using FOP on a NT server or a PC on one side, or on a unix platform on the other side. Is it normal ? Is FOP built to run on PC or NT ? As it is a java library, it is supposed to work on all platform ? Thanks. Nicolas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Performance difference between Unix and PC
Below I've pasted an excerpt from a post to this board a few months back. I also posted a variation of the same question on the Weblogic.performance newsgroup. The answer I got back was that basically that performance difference didn't sound surprising considering the processor speed. Which came a as a big surprise to a lot of our IT guys here who were convinced that RISC was supposed to smoke Pentium at any speed. I have a theory that the speed difference is because Java (and the hotspot implementation in particular) is much better tuned for Windows than HP-UX. I never got an explanation as to why Weblogic degraded so much more running two large reports on the UNIX box. So we know run one Weblogic instance per CPU, basically because of FOP. original email subj:benchmarking question To benchmark I used FOP to render a 200 page PDF document from an XSLT transform on a static XML-file (no database connection is involved). The XSLT transform takes very little time compared to the FOP renderer. I've attached a smaller, but otherwise identical version of the PDF doc I'm using to benchmark. I've tried a DomSource for input, a SaxSource, and the XSLTInputHandler. The results are almost exactly the same in each case. Below are the results I see. Initial heap size=max heap size in each case. Each server is running the latest JDK 131 (w/Hotspot). (I have set all the HP system variables (max_thread_proc, etc.) to Sun recommendations.) Nt dev box (NT4-Worksatation, PIII-933mhz, 512MB ram): Heap Size=64M, 1 report = 251ms/page Heap Size=64M, 2 reports = 750ms/page Heap Size=256M, 1 report = 245ms/page Heap Size=256M, 2 reports = 500/page HP server (HP-Unix, 2x550 mhz, 2GB ram): Heap Size=64M, 1 report = 545ms/page (frequent out of memory errors) Heap Size=64M, 2 reports = didn't try Heap Size=256M, 1 report = 372ms/page Heap Size=256M, 2 reports = 1700ms/page Heap Size=512M, 1 report = 350ms/page Heap Size=512M, 2 reports = 1675ms/page The only difference I can see for sure between the two boxes is that the NT machine performs at least 10 times as much garbage collection. (Sometimes several times per page, as opposed to once every 8-10 pages on the Unix box.) Garbage collection occurs a little more frequenly on the HP box when I lower the heap size, but still not nearly as often as on the NT--at any heap size. Also the HP box runs out of memory if I lower the heap size. I was hoping this was due to some HP setting, but I'm starting to come to the conclusion that it's just some difference in the hotspot implementations. Matt Savino Quest Diagnostics -Original Message- From: Jens Eckert [mailto:[EMAIL PROTECTED]] 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 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 this UNIX machineas it has to handle the load of 30 developers, everybody with own processes of our backend system which is very performance consuming. But would be interesting to know wether this is the case or if FOP is really slower on UNIX. Does anybody know? Jens GUILBERT Nicolas SIReS schrieb: Who can explain the huge performance difference we experience between using FOP on a NT server or a PC on one side, or on a unix platform on the other side. Is it normal ? Is FOP built to run on PC or NT ? As it is a java library, it is supposed to work on all platform ? Thanks. Nicolas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Performance
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 18, 2001 12:29 AM To: [EMAIL PROTECTED] Subject: Performance I have performance problems with Fop on Linux for S390. The same document (for example 4 tables on one page) takes 3 seconds on Win NT, while it takes more than one minute on Linux. The same happens with examples which came with FOP - they are slow on Linux. What should I do? Thanks!!
Re: Performance
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 don't see the same degradation. I'm sure BEA support will figure out this problem in no time. To benchmark I used a servlet with embedded FOP to render a 200 page PDF document from an XSLT transform on a static XML-file (no database connection is involved). Both boxes are running Weblogic 6.1. The XSLT transform takes very little time compared to the FOP renderer. I've tried a DomSource for input, a SaxSource, and the XSLTInputHandler. The results are almost exactly the same in each case. Below are the results I see. Initial heap size=max heap size in each case. Each server is running the latest JDK 131 (w/Hotspot). (I have set all the HP system variables (max_thread_proc, etc.) to Sun recommendations.) Nt dev box (NT4-Worksatation, PIII-933mhz, 512MB ram): Heap Size=64M, 1 report = 251ms/page Heap Size=64M, 2 reports = 750ms/page Heap Size=256M, 1 report = 245ms/page Heap Size=256M, 2 reports = 500/page HP server (HP-Unix, 2x550 mhz, 2GB ram): Heap Size=64M, 1 report = 545ms/page (frequent out of memory errors) Heap Size=64M, 2 reports = didn't try Heap Size=256M, 1 report = 372ms/page Heap Size=256M, 2 reports = 1700ms/page Heap Size=512M, 1 report = 350ms/page Heap Size=512M, 2 reports = 1675ms/page The only difference I can see for sure between the two boxes is that the NT machine performs at least 10 times as much garbage collection. (Sometimes several times per page, as opposed to once every 8-10 pages on the NT box.) Garbage collection occurs a little more frequenly on the HP box when I lower the heap size, but still not nearly as often as on the NT--at any heap size. Also the HP box runs out of memory if I lower the heap size. I was hoping this was due to some HP setting, but I'm starting to come to the conclusion that it's just some difference in the hotspot implementations. Amit wrote: Yup I run it under Linux and it is actually way faster than windowsNT or 98. I have the latest kernel 2.4.12 and am using jdk1.2.2 with 128MB or RAM this is in my development environment. Jim Wright wrote: 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 18, 2001 12:29 AM To: [EMAIL PROTECTED] Subject: Performance I have performance problems with Fop on Linux for S390. The same document (for example 4 tables on one page) takes 3 seconds on Win NT, while it takes more than one minute on Linux. The same happens with examples which came with FOP - they are slow on Linux. What should I do? Thanks!! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Performance
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 performance problems with Fop on Linux for S390. The same document (for example 4 tables on one page) takes 3 seconds on Win NT, while it takes more than one minute on Linux. The same happens with examples which came with FOP - they are slow on Linux. What should I do? Thanks!!
Re: Performance
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 when putting 2 blocks in a cell and specifying the first one as keep-with-next. The blocks are splitted. fo:table-cell requires at least one block-level child (block or image etc) or nothing. regards, Enrico - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Performance
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. There will be probably some changes with the redesign. However, the approach taken by Xalan may also be useful in FOP. In Xalan 2, the DOM has been replaced by DTM (Document Table Model) which uses tables of integers to represent the document, reducing all comparisons (of node names, etc.) to integer comparisons. Of course, Xalan benefits mostly with the faster XPath axis iterators of this implementation which are not relevant to FOP. Nevetherless, if not performance, DTM or the appropiate for FOP offers a lot of savings on memory usage. Just a few thoughts, it may trigger some ideas. Carlos Hi, Carlos Hopefully the high-level design will identify the set of questions that we must pose to the FO tree and area tree structures (I quote those terms to indicate that they are conceptual trees, and an implementation can do whatever it likes). At the moment we really do not have a good handle on exactly what those questions are - we can all think of some of them, but we have no master comprehensive list that can then inform detailed design and implementation. I agree with you...it's a good idea to be aware of what sister projects are doing in terms of data structures. Regards, Arved Fairly Senior Software Type e-plicity (http://www.e-plicity.com) Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Performance and java 1.1
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. Other changes may also be needed. About threading issues: There is only a problem if the HashMap is being added to at the same time as it is also being added to or being read from. This is simple for the main use, properties and elements where the adding can be put into a synchronized block. The advantage is that it is possible to read from two threads at the same time where hastable would prevent this. I think in most of our data it should be fairly easy to handle. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Performance and java 1.1
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 1.1.8 compatible. We are currently able to run FOP 0.20.1 on Kaffe using our own derivation of AWTRenderer. So unofficial -1 on dropping jdk 1.1 support :) Mikko Honkala X-Smiles http://www.x-smiles.org/ -Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Sent: 21. syyskuuta 2001 11:36 To: [EMAIL PROTECTED] Subject: Performance and java 1.1 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. There are three types of tests. I have used 6 fo documents that are generated 500 times. - for each document a new jvm is started, so 3000 documents in 3000 jvm's in serial (about 344m) - use only one jvm for all documents and create them all in serial (about 57m) - use one jvm and a thread for each document, each thread then does that document 500 times (a long time) The actual numbers will depend on the documents size, complexity and inclusion of certain elements such as graphics. The threaded test will also depend on how many threads are using fop at the same time. This is mainly to give a general idea. 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 others who may be using fop in a threaded environment. The time is changed from being twice as slow as serial to faster than serial. So the question is: can we drop java 1.1 support and use better data structures? These numbers are for 6 documents 8 times each. -- With Hashtable 6 documents x 8 One JVM in serial user 1m2.040s user 1m2.560s Threaded user 1m54.780s user 1m56.580s --- With HashMap One JVM in serial user 0m59.260s Threaded user 0m44.780s user 0m45.660s user 0m45.700s This is the user time using unix time which is actual processor time for the process. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Performance and java 1.1
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 perspective of 60% performance improvements is certainly enticing... -- Bertrand Delacrétaz, www.codeconsult.ch -- web technologies consultant - OO, Java, XML, C++ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Performance and java 1.1
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, 2001 3:36 AM To: [EMAIL PROTECTED] Subject: Performance and java 1.1 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. There are three types of tests. I have used 6 fo documents that are generated 500 times. - for each document a new jvm is started, so 3000 documents in 3000 jvm's in serial (about 344m) - use only one jvm for all documents and create them all in serial (about 57m) - use one jvm and a thread for each document, each thread then does that document 500 times (a long time) The actual numbers will depend on the documents size, complexity and inclusion of certain elements such as graphics. The threaded test will also depend on how many threads are using fop at the same time. This is mainly to give a general idea. 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 others who may be using fop in a threaded environment. The time is changed from being twice as slow as serial to faster than serial. So the question is: can we drop java 1.1 support and use better data structures? These numbers are for 6 documents 8 times each. -- With Hashtable 6 documents x 8 One JVM in serial user 1m2.040s user 1m2.560s Threaded user 1m54.780s user 1m56.580s --- With HashMap One JVM in serial user 0m59.260s Threaded user 0m44.780s user 0m45.660s user 0m45.700s This is the user time using unix time which is actual processor time for the process. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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 usable in Applets which is the only sensible reason for supporting JDK 1.1 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. Alex = Alex McLintock[EMAIL PROTECTED]Open Source Consultancy in London OpenWeb Analysts Ltd, http://www.OWAL.co.uk/ SF and Computing Book News and Reviews: http://news.diversebooks.com/ Get Your XML T-Shirt t-shirt/ at http://www.inversity.co.uk/ Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Performance and java 1.1
Committers only get votes on the projects they're comitters for. Non-committers are encouraged to provide input without voting. Loose projects with a lot of committers get upset when non-committers confuse the tally by using +1 in their input, so if you preface your comments with, I don't get a vote, but I'd be +1 because I think... no one will be confused. The PMC can step in an overrule a wayward project full of committers, but that's almost unheard of. -Steve -Original Message- From: Alex McLintock [mailto:[EMAIL PROTECTED]] Sent: Friday, September 21, 2001 12:52 PM To: [EMAIL 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 usable in Applets which is the only sensible reason for supporting JDK 1.1 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. Alex = Alex McLintock[EMAIL PROTECTED]Open Source Consultancy in London OpenWeb Analysts Ltd, http://www.OWAL.co.uk/ SF and Computing Book News and Reviews: http://news.diversebooks.com/ Get Your XML T-Shirt t-shirt/ at http://www.inversity.co.uk/ Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Performance and java 1.1
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 http://xml.apache.org/decisions.html So you are allowed to vote but it won't count ;-) Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
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 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 java 1.4 just around the corner, I think we can and should byte the bullet and stop trying to keep FOP compilable with Java 1.1. I know there are a few loyal Fop users out there whose corporate structures are still several versions behind. It's too bad for them, but FOP _is not_ legacy software and should be able to move quickly. It's also hard for us to keep the code compatible since I suppose almost all of us are developing on at least Java 1.2. So +1 for me. Karen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Performance and java 1.1
I was not sure if we were actually taking a vote yet... Anyhow my vote is: +1 to change the minimum required JVM version to 1.2. As has been mentioned previously, FOP already does not work with JDK 1.1 anymore (since Batik). I am one of the poor souls stuck with JDK 1.1 (at least until next year anyway). We have been able to make a version of FOP that works under JDK 1.1 using some 0.20 code and some old SVG stuff, but it was a royal pain. (Actually Badri R did most of the work on this for me). But I agree that at this point FOP needs to move ahead. Art (works for EastPoint Technologies - 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 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 java 1.4 just around the corner, I think we can and should byte the bullet and stop trying to keep FOP compilable with Java 1.1. I know there are a few loyal Fop users out there whose corporate structures are still several versions behind. It's too bad for them, but FOP _is not_ legacy software and should be able to move quickly. It's also hard for us to keep the code compatible since I suppose almost all of us are developing on at least Java 1.2. So +1 for me. Karen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Performance and java 1.1
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 others who may be using fop in a threaded environment. The time is changed from being twice as slow as serial to faster than serial. So the question is: can we drop java 1.1 support and use better data structures? Keiron, Sounds good to me. I have been assuming the Collections framework in the tinkering that I have been doing. There had been some discussion earlier, and the only contributor to that discussion who was actually stuck on 1.1 (Alex) had encouraged FOP to move on. One point though: when you changed the HashTable to a HashMap, you lost synchronization. In the new design, there are going to be threads, so all shared access structures will need to be synchronized. It would be interesting to see how much of the improvement disappears when the HashMap accesses are synchronized. Peter -- Peter B. West [EMAIL PROTECTED] http://powerup.com.au/~pbwest Lord, to whom shall we go? -- Peter B. West [EMAIL PROTECTED] http://powerup.com.au/~pbwest Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Performance Problems - More Findings
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 answer.] and send this straight to FOP. This brought the total rendering time down from 30 seconds to about 17 seconds, which exceeds the saving observed by Weiqi earlier when using Saxon. I realize that the time that is spent in XSLT vs. in XSL-FO is dependent on the complexity of the original XML, of the XSLT stylesheet, and of the resulting FO. I could imagine a very simple XSLT working on a very simple XML to generate a fairly complicated FO, as is the case for the AllElements example. Or it could be the other way around. These could change the proportions of the time wildly. If you spend significant time in XSLT, then using a faster transformer makes sense. Unfortunately, there is no faster XSL-FO transformers that we can substitute FOP with (the eval version of The Other FO processor---I don't want to mention names to make you cross either---seems to be even slower than FOP at certain inputs). One thing I tested early on was to interface the XSLT results into FOP in various ways: Stream, SAX, and DOM. And there doesn't seem to be any time savings I can wring out by using a DOM vs. an in memory string wrapped up in a InputSource. FOP parses whatever that's input again anyway. -- Weiqi Gao [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Performance Problems
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 tried Mark's Fop.jar, which saves me about 4 to 6 seconds on this, but it still seems excessive. I think it has everything to do with the way I am invoking FOP. I'm calling fop from the command line, using the runnable Jar. The call looks like this: d:\jdk\bin\java.exe -classpath d:\jdk\lib\tools.jar;d:\jdk\lib\classes.zip;d:\fop\lib\ant.jar;d:\fop\lib\w3 c.jar;d:\fop\lib\buildtools.jar;d:\fop\lib\xerces-1.2.3.jar;d:\fop\lib\xalan -2.0.0.jar;d:\fop\lib\xalanj1compat.jar;d:\fop\lib\bsf.jar;d:\fop\lib\jimi-1 .0.jar;d:\fop\fop.jar;d:\fop\lib\xerces.jar;d:\fop\lib\xalan.jar;d:\fop\lib\ bsf.jar -jar d:\fop\fop.jar -xml test.xml -xsl test.xsl -pdf test.pdf The class path came from the RunTest.bat, which was the only example that I could find at the time. There's probably all sorts of things in there that I don't need. When we first started playing with FOP, it was with Cocoon. The document we were testing with was only 5 pages, but the processing time was much less, only a few seconds. Because the cocoon distributable didn't cme with the latest FOP, and we wanted to use v0.19, we went for the command line option. It also fits in better with how we are using FOP. I apologise for being a Java ignoramus, but can anyone give me a pointer on what might be happening here? That's because you're starting a new VM for every document you're creating. First the VM is started (expensive operation), then all classes have to be loaded which also takes a long time. Processing in Cocoon was faster because all FOP classes were already loaded after the first call. How to improve your situation depends on how FOP fits into your project. If your application is written in Java, I encourage you to look at http://xml.apache.org/fop/embedding.html to see how to embed FOP into your application. Of course, that means taking fop.jar and a few other jars into your project class path. Unfortunately, the page above only shows how to call FOP. The part where XSLT comes into play is missing. I think you will find material on that in the mailing list archive. Probably, this page will have to be improved. Volunteers? Jeremias Märki mailto:[EMAIL PROTECTED] OUTLINE AG Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern Fon +41 (41) 317 2020 - Fax +41 (41) 317 2029 Internet http://www.outline.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Performance Problems
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 installed with cocoon does not have the level of FO compliance that we need. One thing to be careful of is, who is doing the talking about compiling Java classes as COM components? Whenever I have run across references to doing this, it's been about using MS Visual J++ to compile the Java. This may be something you want to explore, nevertheless. I am just pointing out that in this discussion compile has different meanings. Failing that, if we are talking about compiling with javac or Jikes or whatever, you are left with compiled bytecode, and for that we have to have a JVM. No ifs and buts. So then the avenue of inquiry leads down looking at the Invocation API in JNI. Sun doesn't seem to be as much help on this as they could. They leaped way ahead and have provided an early-access COM-EJB bridge; if you had FOP all wrapped up inside a session bean you'd be all set. :-) This is interesting and I'll see what I can find out further. Regards, Arved Sandstrom Fairly Senior Software Type e-plicity (http://www.e-plicity.com) Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Performance Problems
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 Cocoon 2? I think it currently includes FOP 0.18. I think from this version it's just a matter of replacing fop.jar to get the latest version running. I'm sure there are people around who did that already. Maybe you could implement a simple HTTP-Proxy (that calls Cocoon) in place of the code that calls FOP now. Just an idea. Jeremias Märki mailto:[EMAIL PROTECTED] OUTLINE AG Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern Fon +41 (41) 317 2020 - Fax +41 (41) 317 2029 Internet http://www.outline.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
