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 one reason for that is pointless class lookups in
the GTK peer code.
Look at this:
Java_gnu_java_awt_peer_gtk_FreetypeGlyphVector_getKerning
(JNIEnv *env, jobject obj __attribute__((unused)), jint rightGlyph, jint leftGlyph, jlong fnt)
{
...
cls = (*env)->FindClass (env, "java/awt/geom/Point2D$Double");
method = (*env)->GetMethodID (env, cls, "<init>", "(DD)V");
return (*env)->NewObjectA(env, cls, method, values);
}
Now, this method only returns a pair of points, and it would have been
trivial to pass a 2-element array into it, fill, with x and y, and
return the same array. But no, we do a class lookup on
java/awt/geom/Point2D$Double and call its constructor with two
double values.
I don't know if this gross inefficiency in the GTK peer is the whole
cause of your pain, but it's a lot of it.
Andrew.
