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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Andrew.


[Index of Archives]     [Linux Kernel]     [Linux Cryptography]     [Fedora]     [Fedora Directory]     [Red Hat Development]

  Powered by Linux