From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: hanwen@byrd.xs4all.nl (Han-Wen Nienhuys) Newsgroups: gmane.lisp.guile.devel Subject: Re: GC improvements Date: Fri, 23 Dec 2005 11:29:57 +0000 (UTC) Organization: LilyPond development Message-ID: References: <87slsnk9u0.fsf@laas.fr> Reply-To: hanwen@xs4all.nl NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1135343604 2255 80.91.229.2 (23 Dec 2005 13:13:24 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 23 Dec 2005 13:13:24 +0000 (UTC) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Dec 23 14:13:23 2005 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EpmjT-00013f-LR for guile-devel@m.gmane.org; Fri, 23 Dec 2005 14:13:15 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EpmkW-0001O7-Ph for guile-devel@m.gmane.org; Fri, 23 Dec 2005 08:14:20 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EplDb-0002x8-CR for guile-devel@gnu.org; Fri, 23 Dec 2005 06:36:21 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Epl9o-0002h7-8L for guile-devel@gnu.org; Fri, 23 Dec 2005 06:32:42 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Epl8o-0002dR-1B for guile-devel@gnu.org; Fri, 23 Dec 2005 06:31:19 -0500 Original-Received: from [80.91.229.2] (helo=ciao.gmane.org) by monty-python.gnu.org with esmtp (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.34) id 1Epl85-0005rI-0n for guile-devel@gnu.org; Fri, 23 Dec 2005 06:30:33 -0500 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Epl7b-0000JR-6b for guile-devel@gnu.org; Fri, 23 Dec 2005 12:30:03 +0100 Original-Received: from muurbloem.xs4all.nl ([213.84.26.127]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 23 Dec 2005 12:30:03 +0100 Original-Received: from hanwen by muurbloem.xs4all.nl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 23 Dec 2005 12:30:03 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-To: guile-devel@gnu.org Original-Lines: 39 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: muurbloem.xs4all.nl X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: hanwen@byrd.xs4all.nl (Han-Wen Nienhuys) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:5550 Archived-At: In article <87slsnk9u0.fsf@laas.fr>, Ludovic Courtès wrote: >The workload I used is quite similar to what happens at startup time: >new objects are created, new symbols are defined, and that's it. The >symbols created (and even the numbers created) are expected to stay >alive until the end of the program. Thus, intuitively, one might say >that there is nothing to collect in this program, so no need to >mark/sweep all the time. I think that GUILE creates garbage as a side effect of evaluating code. If think that nothing needs to be swept, try disabling GC during startup, and see how well it performs memory-wise. >Therefore, my question is: how can we improve on this? > >As I understand it, generational GC could help solve this. However, >being unfamiliar with this, I fail to see how this could be integrated, >and how much work is required. For startup time, I think the best (as in: quickest) would be undump a previous run, instead of recalculating all the initialization on every run. Not only does this save on GC time, it also bypasses all evaluation. Isn't this what Emacs also does? Personally, I think it is much more interesting to optimize for efficiency on longer projects. BTW, I propose that the GC yields are changed a bit. I've heard other people comment that GUILE is dead slow compared to PLT Scheme. I've investigated with one Boehm's GC benchmarks, and for this case it turns out that increasing GC minimum yields sped GUILE up by a factor 1.5 or so. Han-Wen P.S. what's keeping back the GUILE 1.8 release? _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel