From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Andreas Rottmann Newsgroups: gmane.lisp.guile.user Subject: Re: New g-wrap supported in guile-gtk--rotty-0.1! Date: Thu, 04 Dec 2003 23:33:19 +0100 Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Message-ID: <87oeuotdqo.fsf@alice.rotty.yi.org> References: <87smkc5b22.fsf@alice.rotty.yi.org> <874qwhsa2u.fsf@zip.com.au> <87ad69j6ps.fsf@alice.rotty.yi.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1070577414 14860 80.91.224.253 (4 Dec 2003 22:36:54 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 4 Dec 2003 22:36:54 +0000 (UTC) Cc: guile-user@gnu.org, guile-gtk-general@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Thu Dec 04 23:36:50 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 1AS25a-0006CR-00 for ; Thu, 04 Dec 2003 23:36:50 +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 1AS31p-0000mu-BI for guile-user@m.gmane.org; Thu, 04 Dec 2003 18:37:01 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AS30M-0000fX-P8 for guile-user@gnu.org; Thu, 04 Dec 2003 18:35:30 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AS2zp-0000S7-26 for guile-user@gnu.org; Thu, 04 Dec 2003 18:35:29 -0500 Original-Received: from [213.165.64.20] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.24) id 1AS2zo-0000RB-HC for guile-user@gnu.org; Thu, 04 Dec 2003 18:34:56 -0500 Original-Received: (qmail 4638 invoked by uid 65534); 4 Dec 2003 22:33:30 -0000 Original-Received: from chello213047125140.14.univie.teleweb.at (EHLO garibaldi) (213.47.125.140) by mail.gmx.net (mp007) with SMTP; 04 Dec 2003 23:33:30 +0100 X-Authenticated: #3102804 Original-Received: from ivanova.rhinosaur.lan ([192.168.1.9] helo=ivanova) by garibaldi with esmtp (Exim 4.24) id 1AS22B-0002T2-Cj; Thu, 04 Dec 2003 23:33:19 +0100 Original-Received: from andy by ivanova with local (Exim 4.24) id 1AS22B-0005It-AH; Thu, 04 Dec 2003 23:33:19 +0100 Original-To: djurfeldt@nada.kth.se In-Reply-To: (Mikael Djurfeldt's message of "Thu, 04 Dec 2003 09:14:18 -0500") User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) X-Spam-Score: -4.9 (----) 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:2444 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:2444 Mikael Djurfeldt writes: >> 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). > Unfortunatly, I guess this will not help much. First, most generics in the binding have only one method. Second, I'm not exactly sure how to get complexity down: compute-new-methods currently checks each of current methods against a duplicate specialization. However, it may be save to assume that all methods passed to internal-add-methods! have different specializers, so I could at least add them if there are not any methods yet. > 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. > Hmm, this would probably mean pulling internal-add-methods! and (part of) the functions it calls down to the C level. What exactly do I have to consider wrt MOP here? Andy -- Andreas Rottmann | Rotty@ICQ | 118634484@ICQ | a.rottmann@gmx.at http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 Any technology not indistinguishable from magic is insufficiently advanced. -- Terry Pratchett _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user