Ziga Mahkovec writes: > I upgraded to libgcj-4.0.0-0.32 and eclipse-ecj-3.1.0_fc-0.M5.12. > The results for compiling classpath: > > ecj | ecj-native | jikes > ------------------------------------------------------------- > real 1m31.786s | real 0m16.207s | real 0m8.423s > user 1m22.796s | user 0m14.925s | user 0m7.052s > sys 0m1.369s | sys 0m1.020s | sys 0m0.755s > > (ecj-native went from 24.5s to 16.2s as a result of -O2) > > I also uploaded oprofiles for ecj[1], ecj-native[2] and ecj-native-with- > the-old-gcjlib-tools-jar[3]. > > Note that I'm running a Centrino so the oprofile driver falls back to > timer interrupt mode. > > [1] http://www.bootchart.org/misc/ecj/M5.12/opreport.ecj.log > [2] http://www.bootchart.org/misc/ecj/M5.12/opreport.ecj-native.log > [3] http://www.bootchart.org/misc/ecj/M5.12/opreport.ecj-native-gcjlib.log Thank you very much for doing this. It's very useful. Jikes is famously fast, so I'm fairly pleased to see we're close. It says here: "[Jikes] is astoundingly fast -- hundreds of thousands of lines of code per minute (about ten times faster than other compilers)" There are some surprises here. Is ecj fully interpreted code? _Jv_InterpMethod::run seems only to take 0.0036% of the time. I'm going to investigate some more. I'm sure that ecj-native isn't purely native code, because of this line: 399 2.2024 libgcj.so.6.0.0 _Jv_BytecodeVerifier::verify_instructions_0() which is weird. Thanks again, Andrew.
