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
Absolutely, +1. At 05:12 PM 9/21/01 -0400, Art Welch wrote: >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] > > 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
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 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, > > 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
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
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 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
> 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 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
Keiron Liddle wrote: [..] > So the question is: can we drop java 1.1 support and use better data > structures? +1 (I think we should make this an "official vote") and AFAIK at the moment fop does not work with jdk1.1 anyway... Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Performance and java 1.1
I would add to the consensus here ... I believe that requiring Java 2 collection classes is more than reasonable, particularly for this project. I'm not sure that anyone is going to have much success deploying bleeding edge technologies like XSL:FO if they are trapped in a 2-3 year old Java platform. All customers I am working with who are doing PDF rendering with FOP are all on 1.3, 1.3.1 JVMs ... they are early adopters and technophiles by definition. The other guys are still using TeX ;-) Besides, 1.1 users can work around the use of Java 2 collection classes if they absolutely have to, by using Sun's collections.jar and changing the package imports in the source code. - Rob - 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
> 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]
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]