From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Dirk Herrmann Newsgroups: gmane.lisp.guile.user Subject: Re: MEMOIZE_LOCALS (fwd) Date: Fri, 28 Jun 2002 01:39:08 +0200 (CEST) Sender: guile-user-admin@gnu.org Message-ID: References: NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: main.gmane.org 1025221336 21381 127.0.0.1 (27 Jun 2002 23:42:16 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 27 Jun 2002 23:42:16 +0000 (UTC) Cc: guile-user@gnu.org Return-path: Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17Niu0-0005Yk-00 for ; Fri, 28 Jun 2002 01:42:16 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17Nitp-00060i-00; Thu, 27 Jun 2002 19:42:05 -0400 Original-Received: from sallust.ida.ing.tu-bs.de ([134.169.132.52]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17Nir5-0005XA-00 for ; Thu, 27 Jun 2002 19:39:15 -0400 Original-Received: from localhost (dirk@localhost) by sallust.ida.ing.tu-bs.de (8.9.3+Sun/8.9.1) with ESMTP id BAA06532; Fri, 28 Jun 2002 01:39:08 +0200 (CEST) Original-To: ttn@glug.org In-Reply-To: Errors-To: guile-user-admin@gnu.org X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.user:658 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:658 On Thu, 27 Jun 2002, Thien-Thi Nguyen wrote: > From: Dirk Herrmann > Date: Thu, 27 Jun 2002 23:24:56 +0200 (CEST) > > I posted this to the guile-devel list, but I think it could be of > interest to people on the guile-user list as well. So far, I have > got positive feedback from Marius for the change indicated below. > Thus, I urge people who disagree to this change to speak up. > Otherwise I will go ahead and remove the MEMOIZE_LOCALS macro. > > this is a good opportunity to put in place performance testing framework > so we can see what kind of impact changes like this have. you can make > statements like "benchmarks/memoize-locals.test shows 3% degradation w/ > this change in local testing". people can then learn to judge whether > or not such a change is under their noise threshold, and over time learn > to trust your methods. any plans to do this? While in principle a performance testing framework is a good idea, it won't help at all in the case discussed above: The change, if applied as suggested above, will only remove code that (if my assumptions about people not making use of the MEMOIZE_LOCALS macro are right) is not compiled into guile anyway. Thus, the intention of the change is to simplify the code by removing a lot of dead #ifdef code parts, making the relevant parts of the code better readable. Apart from this, I think there has been discussion about a benchmark suite from time to time, but I can't tell about the current state. Personally, I don't have any plans to work on such a thing, but I would sure appreciate if someone else likes to do so. Performance is certainly an important quality for software, but it is not the only one. My personal interest is on code readability, architectural cleanlyness, ease of use (by means of providing a consistent and simple API) and such qualities. Regarding my 'methods', I don't think there is much need to justify them. Typically I think of ways to improve guile, suggest changes and discuss with people whether these changes will make sense or not. If there is a consensus and I find the time (time is the most critical part!), I will apply the changes. So far, there have been only few complaints :-) Best regards Dirk Herrmann _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user