From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <java-return-25775-listarch-java=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 4102 invoked by alias); 6 Nov 2008 13:40:29 -0000
Received: (qmail 4086 invoked by uid 22791); 6 Nov 2008 13:40:29 -0000
X-Spam-Check-By: sourceware.org
Received: from cp-out3.libero.it (HELO cp-out3.libero.it) (212.52.84.103)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 06 Nov 2008 13:39:47 +0000
Received: from libero.it (192.168.17.4) by cp-out3.libero.it (8.5.016.1)         id 4912CBFE00050DC7; Thu, 6 Nov 2008 14:39:34 +0100
Date: Thu, 06 Nov 2008 13:40:00 -0000
Message-Id: <K9WZ9Y$0DBCD008EE6ABA1BF31318A9F51108EC@libero.it>
Subject: Re: [GCJ] Performance of GUI applications on embedded systems
MIME-Version: 1.0
X-Sensitivity: 3
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
From: "ffileppo" <ffileppo@libero.it>
To: "aph" <aph@redhat.com>
Cc: "java" <java@gcc.gnu.org>, 	"classpath" <classpath@gnu.org>
X-XaM3-API-Version: 4.3 (R1) (B3pl25)
X-SenderIP: 130.192.86.37
X-IsSubscribed: yes
Mailing-List: contact java-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <java.gcc.gnu.org>
List-Id: <java.gcc.gnu.org>
List-Subscribe: <mailto:java-subscribe@gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/java/>
List-Post: <mailto:java@gcc.gnu.org>
List-Help: <mailto:java-help@gcc.gnu.org>, <http://gcc.gnu.org/ml/#faqs>
Sender: java-owner@gcc.gnu.org
X-SW-Source: 2008-11/txt/msg00026.txt.bz2

> 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.
>
> Andrew.
>


Hi Andrew,

I'm testing your patch on my embedded system and now I can see that GUI per=
formance 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 usag=
e is always at 100% (after the application is running),
so the responsiveness is still not very good.

Do you think that there is still some places for improvement?
I'll try to use oprofile on my embedded system to see what's going wrong

Best Regards,

Francesco