Bryce McKinlay writes: > Ziga Mahkovec wrote: > > >Ah, much better, thanks. Here are the revised times (BTW, that's a > >1.5GHz Pentium M): > > > >HelloWorld > > > >ecj | ecj-native | jikes > >------------------------------------------------------------- > >real 0m1.863s | real 0m1.614s | real 0m0.067s > >user 0m1.758s | user 0m1.536s | user 0m0.050s > >sys 0m0.103s | sys 0m0.076s | sys 0m0.012s > > > > > >GNU Classpath (cd lib; make) > > > >ecj | ecj-native | jikes > >------------------------------------------------------------- > >real 1m24.539s | real 0m24.552s | real 0m9.439s > >user 1m23.157s | user 0m23.047s | user 0m7.486s > >sys 0m1.142s | sys 0m1.139s | sys 0m0.771s > > > > > >Note that classpath sources need a tiny hack to keep ecj from crashing. > >But that looks like an upstream Eclipse bug, since I could reproduce it > >running ecj with java-1.5.0-sun. > > > >Andrew, I don't suppose you still need oprofile data (or are there other > >places where gcjlib:// loading might be a problem)? It's not so very important now, but it is still interesting. By the way, if you're not used to oprofile: the docs make it look heinously difficult to use, but it's really very easy! The only hard part is reading the docs... I do sudo sh -c 'opcontrol --reset ; opcontrol --start'; ./a.out trash flibber poo; sudo sh -c 'opcontrol --stop' to measure a job, then sudo opreport -l to get the report. It's really that easy. The trouble with very short runtimes like this one is that you might not have enough samples. > The ecj-native times still look somewhat slow. Back in the RHUG days, a > gcj-compiled ecj was faster than jikes at building classpath. Perhaps > the BC-ABI stuff is slowing us down a bit. Yeah. Oprofile might still be interesting. Andrew.
