Re: [GCJ] Performance of GUI applications on embedded systems

[Andrew Haley <aph at redhat dot com>]

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.