From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Mikael Djurfeldt Newsgroups: gmane.lisp.guile.user Subject: Re: New g-wrap supported in guile-gtk--rotty-0.1! Date: Thu, 04 Dec 2003 09:14:18 -0500 Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Message-ID: References: <87smkc5b22.fsf@alice.rotty.yi.org> <874qwhsa2u.fsf@zip.com.au> <87ad69j6ps.fsf@alice.rotty.yi.org> Reply-To: djurfeldt@nada.kth.se NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1070547661 21430 80.91.224.253 (4 Dec 2003 14:21:01 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 4 Dec 2003 14:21:01 +0000 (UTC) Cc: guile-user@gnu.org, djurfeldt@nada.kth.se, guile-gtk-general@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Thu Dec 04 15:20:57 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1ARuLh-0000tv-00 for ; Thu, 04 Dec 2003 15:20:57 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1ARvIf-0001gG-PS for guile-user@m.gmane.org; Thu, 04 Dec 2003 10:21:53 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1ARvHu-0001fR-Fq for guile-user@gnu.org; Thu, 04 Dec 2003 10:21:06 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1ARvHO-0001YS-5Y for guile-user@gnu.org; Thu, 04 Dec 2003 10:21:05 -0500 Original-Received: from [213.212.20.77] (helo=kvast.blakulla.net) by monty-python.gnu.org with esmtp (Exim 4.24) id 1ARvCv-0000VV-D9; Thu, 04 Dec 2003 10:15:57 -0500 Original-Received: from chunk.mit.edu ([18.42.2.92] helo=chunk ident=mail) by kvast.blakulla.net with esmtp (Exim 3.36 #1 (Debian)) id 1ARuFI-0002oa-00; Thu, 04 Dec 2003 15:14:20 +0100 Original-Received: from mdj by chunk with local (Exim 4.24) id 1ARuFG-0003eV-Kx; Thu, 04 Dec 2003 09:14:18 -0500 Original-To: Andreas Rottmann In-Reply-To: <87ad69j6ps.fsf@alice.rotty.yi.org> (Andreas Rottmann's message of "Thu, 04 Dec 2003 10:02:55 +0100") User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.user:2442 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:2442 Andreas Rottmann writes: > [ CC'd guile-user, since maybe someone has an idea how to implement > this ] > > Kevin Ryde writes: > >> Andreas Rottmann writes: >>> >>> I now get ~3.6 seconds of loading time for (gnome gtk) with the above >>> referenced code, gcc 3.3.2 -O2 and Guile 1.7 on my Athlon 900. The >>> loading time is mostly spent in scm_add_method(), FWIW... >> >> I wonder if some lazy initializing would be possible, like catch a >> failed method dispatch and add only at that time. (But my ignorance >> of goops is pretty profound, so maybe it's not feasible.) >> > I don't really know. Maybe one could postpone the method creation > until the first instance of that class has been instantiated... > >> gtk+gnome is pretty big, there might be a good chance an application >> would use only a modest number of widgets and functions. Those needed >> to get the first window up could be even fewer. (Always good to get >> the first window up quickly, since the user is waiting, waiting ...) >> > Yes, I also think that we *have* to get the "time-to-initial-window" > at least under 1 second for a hello world program... GOOPS is, as yet, only optimized for fast execution. Creation of objects and *especially* method creation involves a lot of work, most of which is done by interpreted Scheme code. This is not an architectural problem, though, and it is certainly possible to speed things up. An improvement of method addition on the algorithm level that could help this particular case would be to allow for adding multiple methods at once. Presently, every call to scm_add_method involves re-computing the methods list of the GF which means that adding N methods to a GF is O(N^2). An improvement on the implementation level would be to do part (or all) of the work in C. This, however, should be done with preserved respect for the MOP. Anyone who wants to do this should talk to me first. (Unfortunately, I can't do any work on GOOPS right now. Hopefully I'll be able to go over a few issues with GOOPS starting next summer.) M _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user