Andrew Haley wrote: > Andrew Haley wrote: >> ffileppo wrote: >> >>> I've been investigating about performance of java code compiled with gcj on embedded systems. >>> In particular I'm interested in testing AWT/SWING application using GTK/Xorg as graphical backend >>> (this is the only viable solution since QT peers are not well supported). >>> >>> The embedded device I've been using for testing is a PXA270 processor (armv5te) equipped with 128Mb Ram; >>> running linux kernel 2.6.24 and using libgcj.so.10. GTK peers are running on Xorg, using matchbox >>> as window manager. The crosscompiler on my host is gcc 4.4. >>> >>> During my tests I've noticed that java code using AWT/SWING (for example the test case attached at the end) >>> with GTK peer cause a very high load on the cpu. >>> Furthermore the applications take a lot of time to load and also the UI responsiveness is very slow. >>> Using "top" I can see that CPU is always at 100% during start up (it takes about 2 minutes >>> to get the application starting, Ram usage is ok). >>> >>> I've also noticed that using optimizations (-O2, -O3...) does not help with graphical performance. >>> >>> [On the same device, running WinCE and a commerical JVM (CrEme), applications have extremely better >>> graphical performance] >>> >>> From my experience with this particual embedded system I can say that gcj has very high performance >>> when dealing with non-gui tasks (e.g. array sorting) compared with most of JVMs but gui >>> performance are very poor. >>> >>> I would like to ask your opinion about the slowness of gui applications in my setup, >>> and also about viable solutions to improve this issue. >>> What do you think is the bottleneck? >>> >>> -- libgcj itself? >>> -- GTK library / GTK peer implementation in classpath? >>> -- something dealing with Xorg? >> We can only speculate. >> >> oprofile is your friend. If you can get oprofile working on your >> target system, please use it and find out if it does what you need. > > I did it. The answer is appended. > > The problem is that the program is spending almost all of the time > generating stack traces, millions and millions of them. And I've found the reason for that. Every time anyone calls gnu.java.awt.peer.gtk.GdkFontPeer$GdkFontMetrics.stringWidth, a call is made to gnu.java.awt.peer.gtk.FreetypeGlyphVector.getKerning, which does this: cls = (*env)->FindClass (env, "java/awt/geom/Point2D$Double"); method = (*env)->GetMethodID (env, cls, "<init>", "(DD)V"); return (*env)->NewObjectA(env, cls, method, values); This call to FindClass does a dynamic lookup of java/awt/geom/Point2D$Double, which requires that the class loaders are invoked in turn. Each one throws a ClassNotFoundException until the class is found. Andrew.
