ffileppo wrote: >>>> Here's one improvement. If you can get rid of the places in the GTK peers >>>> where class and method lookups are performed at runtime you'll probably >>>> have a fix. This shouldn't be a massive amount of work, just rather >>>> boring. >>>> >>>> In gcj, >>>> >>>> * Compiled java code is quite fast. >>>> * Class lookup by name is slow. >>>> * Calling JNI code from compiled java code is quite fast. >>>> * Calling compiled java code from JNI code is slow. >>>> * Exceptions are slow. >>> I'm testing your patch on my embedded system and now I can see that GUI >>> performance are very much better (particularly during application startup). >>> >>> Thank you so much! >>> >>> However running my test case (please see my first post) I see that CPU >>> usage is always at 100% (after the application is running), >>> so the responsiveness is still not very good. >> What do you expect? You're setting up a Timer with a delay of >> 0 milliseconds between events, and it's running continuously. >> >> Andrew. >> > > You're right. > However I'm experiencing slowness when testing some other GUI sample > application (e.g. the test case attached at the end). > > In this particular test case, the application takes a lot of time to startup > (compared to the same device, running WinCE and CrEme JVM) and during start > up the CPU usage is always at 100%. > > After startup, I'v also noticed that highlighting and/or clicking a certain > number of times on buttons cause the application to hang and after that the > CPU usage is always 100%.
I've identified some serious GTK locking problems with this version of gcj. I'm investigating. Andrew.
