From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludovic.courtes@laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.user Subject: Re: What is best way to limit memory alloc? Date: Wed, 29 Aug 2007 17:20:07 +0200 Organization: LAAS-CNRS Message-ID: <87y7fu2wrc.fsf@laas.fr> References: <1188367992.8043.508.camel@localhost.localdomain> <1188382968.8043.578.camel@localhost.localdomain> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1188400828 18859 80.91.229.12 (29 Aug 2007 15:20:28 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 29 Aug 2007 15:20:28 +0000 (UTC) Cc: guile-user@gnu.org To: Roland Orre Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Wed Aug 29 17:20:25 2007 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IQPKx-0006WQ-Vo for guile-user@m.gmane.org; Wed, 29 Aug 2007 17:20:08 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IQPKx-0004Br-O5 for guile-user@m.gmane.org; Wed, 29 Aug 2007 11:20:07 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IQPKs-0004A4-7w for guile-user@gnu.org; Wed, 29 Aug 2007 11:20:02 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IQPKn-000445-Kd for guile-user@gnu.org; Wed, 29 Aug 2007 11:20:01 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IQPKn-00043s-EG for guile-user@gnu.org; Wed, 29 Aug 2007 11:19:57 -0400 Original-Received: from laas.laas.fr ([140.93.0.15]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IQPKn-0008AD-0w for guile-user@gnu.org; Wed, 29 Aug 2007 11:19:57 -0400 Original-Received: from messiaen.laas.fr (messiaen [IPv6:2001:660:6602:0:230:65ff:fed4:9d20]) by laas.laas.fr (8.13.8/8.13.8) with SMTP id l7TFJsuc010089; Wed, 29 Aug 2007 17:19:54 +0200 (MEST) Original-Received: by messiaen.laas.fr (sSMTP sendmail emulation); Wed, 29 Aug 2007 17:20:07 +0200 X-URL: http://www.laas.fr/~lcourtes/ X-Revolutionary-Date: 12 Fructidor an 215 de la =?iso-8859-1?Q?R=E9volutio?= =?iso-8859-1?Q?n?= X-PGP-Key-ID: 0xEB1F5364 X-PGP-Key: http://www.laas.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 821D 815D 902A 7EAB 5CEE D120 7FBA 3D4F EB1F 5364 X-OS: powerpc-unknown-linux-gnu Mail-Followup-To: Roland Orre , guile-user@gnu.org In-Reply-To: <1188382968.8043.578.camel@localhost.localdomain> (Roland Orre's message of "Wed\, 29 Aug 2007 12\:22\:47 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) X-Spam-Score: -0.001 () NO_RELAYS X-Scanned-By: MIMEDefang at CNRS-LAAS on IPv6:2001:660:6602::2 X-Detected-Kernel: Solaris 10 (beta) X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:6116 Archived-At: Roland Orre writes: > I found out that I had already solved the memory allocation > problem in one way a few years ago. > With the help of a small routine gc-heap-size, which accesses > scm_i_master_freelist.heap_size > scm_i_master_freelist2.heap_size > I did: > (define gc-heap1 (gc-heap-size 1)) > (define gc-heap2 (gc-heap-size 2)) > (let loop > .... > (gc-heap-size 1 gc-heap1) > (gc-heap-size 2 gc-heap2) > (loop ...)) > By not allowing the heap size to increase. That seems brutal. ;-) What does `gc-heap-size' do exactly? Another way would have been to fiddle with the `GUILE_MIN_YIELD_1' and `GUILE_MIN_YIELD_2' environment variables. These variables tell the GC when it should grow the heap for the first and second freelist, respectively. More precisely, the GC does: if (number-of-cells-collected-recently < GUILE_MIN_YIELD_X) then allocate-new-heap else run-a-collection (This takes place in `scm_i_gc_grow_heap_p ()' and `scm_gc_for_newcell ()'.) The default value for `GUILE_MIN_YIELD_{1,2}' is 40, which means that if the last GC run did not yield more than 40 cells, then more heap is allocated. If you set it to some _higher_ value, then the GC should be more conservative and less memory-hungry, at the cost of being slower. Thanks, Ludovic. _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user