DO NOT REPLY [Bug 25480] - [PATCH] Experimental performance improvements.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25480. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25480 [PATCH] Experimental performance improvements. --- Additional Comments From [EMAIL PROTECTED] 2003-12-13 07:08 --- John, The foelements.xml that maps properties to elements did not include the shorthand properties. This is fixed now.
DO NOT REPLY [Bug 25480] - [PATCH] Experimental performance improvements.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25480. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25480 [PATCH] Experimental performance improvements. --- Additional Comments From [EMAIL PROTECTED] 2003-12-13 07:08 --- Created an attachment (id=9553) New version of src\codegen\foelements.xml
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
cvs commit: xml-fop build.bat
jeremias2003/12/13 15:23:03 Modified:.build.bat Log: Don't use embedded Ant. An Ant installation is now required. Revision ChangesPath 1.21 +24 -25xml-fop/build.bat Index: build.bat === RCS file: /home/cvs/xml-fop/build.bat,v retrieving revision 1.20 retrieving revision 1.21 diff -u -r1.20 -r1.21 --- build.bat 4 Jul 2003 20:22:25 - 1.20 +++ build.bat 13 Dec 2003 23:23:03 - 1.21 @@ -1,37 +1,36 @@ @echo off +rem $Id$ -echo Fop Build System -echo +echo Apache FOP: Build System +echo -- -if %JAVA_HOME% == goto error +if %JAVA_HOME% == goto no_java_home +if %ANT_HOME% == goto no_ant_home -set LIBDIR=lib -set LOCALCLASSPATH=%JAVA_HOME%\lib\tools.jar;%JAVA_HOME%\lib\classes.zip -set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\ant.jar -set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\xml-apis.jar -set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\xercesImpl-2.2.1.jar -set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\xalan-2.4.1.jar +call %ANT_HOME%\bin\ant.bat %1 %2 %3 %4 %5 %6 %7 %8 -set ANT_HOME_BAK=%ANT_HOME% -set ANT_HOME=%LIBDIR% - -echo Building with classpath %LOCALCLASSPATH% - -echo Starting Ant... - -%JAVA_HOME%\bin\java.exe -Dant.home=%ANT_HOME% -classpath %LOCALCLASSPATH% org.apache.tools.ant.Main %1 %2 %3 %4 %5 - -set ANT_HOME=%ANT_HOME_BAK% goto end -:error - +:no_java_home echo ERROR: JAVA_HOME not found in your environment. echo Please, set the JAVA_HOME variable in your environment to match the echo location of the Java Virtual Machine you want to use. +goto end -:end - -rem set LOCALCLASSPATH= +:no_ant_home +echo ERROR: ANT_HOME not found in your environment. +echo Please install Apache Ant first. FOP uses Ant as its build system. +echo You can download Apache Ant from http://ant.apache.org +echo 1. Download and install Ant +echo 2. Set the ANT_HOME environment variable to the directory where you've +echoplaced Ant. +echo 3. Add %%ANT_HOME%%\bin to your PATH so the ant.bat batch file +echocan be executed from wherever needed. +echo 4. (optional) Download JUnit and place junit-*.jar in %%ANT_HOME%%\lib. +echoThis enables the JUnit test cases. +echo You will now be directed to the Apache Ant website... +pause +start http://ant.apache.org +goto end -pause; +:end - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop build.sh
jeremias2003/12/13 15:23:43 Modified:.build.sh Log: Don't use embedded Ant. An Ant installation is now required. (tested in Cygwin, please test on Unix) Revision ChangesPath 1.24 +20 -30xml-fop/build.sh Index: build.sh === RCS file: /home/cvs/xml-fop/build.sh,v retrieving revision 1.23 retrieving revision 1.24 diff -u -r1.23 -r1.24 --- build.sh 9 Mar 2003 21:21:45 - 1.23 +++ build.sh 13 Dec 2003 23:23:43 - 1.24 @@ -1,8 +1,8 @@ #!/bin/sh # This file should be executable. echo -echo Fop Build System -echo +echo Apache FOP: Build System +echo -- echo if [ $JAVA_HOME = ] ; then @@ -13,6 +13,21 @@ exit 1 fi +if [ $ANT_HOME = ] ; then + echo ERROR: ANT_HOME not found in your environment. + echo + echo Please install Apache Ant first. FOP uses Ant as its build system. + echo You can download Apache Ant from http://ant.apache.org; + echo 1. Download and install Ant + echo 2. Set the ANT_HOME environment variable to the directory where you've + echoplaced Ant. + echo 3. Add \$ANT_HOME/bin to your PATH so the ant script file + echocan be be executed from wherever needed. + echo 4. (optional) Download JUnit and place junit-*.jar in \$ANT_HOME/lib. + echoThis enables the JUnit test cases. + exit 1 +fi + # OS specific support. $var _must_ be set to either true or false. cygwin=false; case `uname` in @@ -21,33 +36,8 @@ # For Cygwin, ensure paths are in UNIX format before anything is touched if $cygwin ; then - [ -n $JAVA_HOME ] -JAVA_HOME=`cygpath --unix $JAVA_HOME` + [ -n $ANT_HOME ] +ANT_HOME=`cygpath --unix $ANT_HOME` fi - -LIBDIR=lib -LOCALCLASSPATH=$JAVA_HOME/lib/tools.jar:$JAVA_HOME/lib/classes.zip -LOCALCLASSPATH=$LOCALCLASSPATH:$LIBDIR/ant.jar -LOCALCLASSPATH=$LOCALCLASSPATH:$LIBDIR/xml-apis.jar -LOCALCLASSPATH=$LOCALCLASSPATH:$LIBDIR/xercesImpl-2.2.1.jar -LOCALCLASSPATH=$LOCALCLASSPATH:$LIBDIR/xalan-2.4.1.jar - -ANT_HOME=$LIBDIR -# antRun must be executable (can't do this in build.xml because Ant uses antRun -# to do the chmod) -chmod +rx $LIBDIR/bin/antRun - - -# For Cygwin, switch paths to Windows format before running java -if $cygwin; then - JAVA_HOME=`cygpath --path --windows $JAVA_HOME` - LOCALCLASSPATH=`cygpath --path --windows $LOCALCLASSPATH` -fi - -echo -echo Building with classpath $LOCALCLASSPATH -echo Starting Ant... -echo - -$JAVA_HOME/bin/java -Dant.home=$ANT_HOME -classpath $LOCALCLASSPATH org.apache.tools.ant.Main $@ +$ANT_HOME/bin/ant $@ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/lib readme
jeremias2003/12/13 15:24:13 Removed: lib readme Log: Remove out-of-date file. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/lib/bin antRun
jeremias2003/12/13 15:24:33 Removed: lib ant.LICENSE.txt ant.jar lib/bin antRun Log: Remove embedded Ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Remove ant.jar and build.bat/sh
I've removed the embedded Ant in HEAD. I rewrote build.bat and build.sh to call a separately installed Ant. Instructions will be given on the command-line if Ant cannot be found. Peter, please test build.sh on Unix. I hope I got the whole thing right. Jeremias Maerki
DO NOT REPLY [Bug 25474] - Test for table-column element in PPColWidthFunction always fail.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25474. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25474 Test for table-column element in PPColWidthFunction always fail. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-12-14 01:57 --- Applied--Thanks! Glen
Re: [PROPOSAL] Remove ant.jar and build.bat/sh
Well done--I particularly liked the Ant instructions you added. Glen --- Jeremias Maerki [EMAIL PROTECTED] wrote: I've removed the embedded Ant in HEAD. I rewrote build.bat and build.sh to call a separately installed Ant. Instructions will be given on the command-line if Ant cannot be found. Peter, please test build.sh on Unix. I hope I got the whole thing right. Jeremias Maerki __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/
DO NOT REPLY [Bug 25480] - [PATCH] Experimental performance improvements.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25480. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25480 [PATCH] Experimental performance improvements. --- Additional Comments From [EMAIL PROTECTED] 2003-12-14 02:24 --- Looking at your patch currently... Glen
