From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29167 invoked by alias); 8 Nov 2008 11:40:47 -0000 Received: (qmail 29107 invoked by uid 22791); 8 Nov 2008 11:40:46 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 08 Nov 2008 11:40:01 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id mA8Bdx3u023274; Sat, 8 Nov 2008 06:39:59 -0500 Received: from zebedee.pink (vpn-12-19.rdu.redhat.com [10.11.12.19]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id mA8Bdurs006690; Sat, 8 Nov 2008 06:39:56 -0500 Message-ID: <49157A8C.5090200@redhat.com> Date: Sat, 08 Nov 2008 11:40:00 -0000 From: Andrew Haley User-Agent: Thunderbird 2.0.0.17 (X11/20080914) MIME-Version: 1.0 To: ffileppo CC: java , classpath Subject: Re: [GCJ] Performance of GUI applications on embedded systems References: <49148F35.8030209@redhat.com> In-Reply-To: <49148F35.8030209@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact java-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-owner@gcc.gnu.org X-SW-Source: 2008-11/txt/msg00032.txt.bz2 Andrew Haley wrote: > 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. Found a very silly (:-) merge error in CairoGraphics2D.c. This fixes it. I don't think there should be any differences between the GTK peers in Classpath and gcj, should there? Or indeed, and differences between the CNI code in Classpath and gcj. Andrew. Index: gnu_java_awt_peer_gtk_CairoGraphics2D.c =================================================================== --- gnu_java_awt_peer_gtk_CairoGraphics2D.c (revision 141575) +++ gnu_java_awt_peer_gtk_CairoGraphics2D.c (working copy) @@ -351,7 +351,6 @@ for (i = 0; i < n; i++) { PangoFcFont *font = JLONG_TO_PTR(PangoFcFont, fonts[i]); - gdk_threads_leave (); /* Draw as many glyphs as possible with the current font */ int length = 0;