From mboxrd@z Thu Jan  1 00:00:00 1970
Path: main.gmane.org!not-for-mail
From: Richard Stallman <rms@gnu.org>
Newsgroups: gmane.emacs.devel
Subject: Re: Does a larger gc-cons-threshold mean a faster Emacs?
Date: Mon, 29 Jul 2002 11:30:08 -0600 (MDT)
Sender: emacs-devel-admin@gnu.org
Message-ID: <200207291730.g6THU8x14005@aztec.santafe.edu>
References: <87ofcu55qt.fsf@openprivacy.org>
	<3405-Sun28Jul2002210711+0300-eliz@is.elta.co.il> <87sn23v2nt.fsf@openprivacy.org>
Reply-To: rms@gnu.org
NNTP-Posting-Host: localhost.gmane.org
X-Trace: main.gmane.org 1027963943 23918 127.0.0.1 (29 Jul 2002 17:32:23 GMT)
X-Complaints-To: usenet@main.gmane.org
NNTP-Posting-Date: Mon, 29 Jul 2002 17:32:23 +0000 (UTC)
Cc: eliz@is.elta.co.il, emacs-devel@gnu.org
Return-path: <emacs-devel-admin@gnu.org>
Original-Received: from quimby.gnus.org ([80.91.224.244])
	by main.gmane.org with esmtp (Exim 3.33 #1 (Debian))
	id 17ZENa-0006Df-00
	for <emacs-devel@main.gmane.org>; Mon, 29 Jul 2002 19:32:22 +0200
Original-Received: from fencepost.gnu.org ([199.232.76.164])
	by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian))
	id 17ZEev-0002Yt-00
	for <emacs-devel@quimby.gnus.org>; Mon, 29 Jul 2002 19:50:17 +0200
Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org)
	by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian))
	id 17ZENz-0001qZ-00; Mon, 29 Jul 2002 13:32:47 -0400
Original-Received: from pele.santafe.edu ([192.12.12.119])
	by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian))
	id 17ZELR-0001Xl-00; Mon, 29 Jul 2002 13:30:09 -0400
Original-Received: from aztec.santafe.edu (aztec [192.12.12.49])
	by pele.santafe.edu (8.11.6+Sun/8.11.6) with ESMTP id g6THUHB18751;
	Mon, 29 Jul 2002 11:30:17 -0600 (MDT)
Original-Received: (from rms@localhost)
	by aztec.santafe.edu (8.10.2+Sun/8.9.3) id g6THU8x14005;
	Mon, 29 Jul 2002 11:30:08 -0600 (MDT)
X-Authentication-Warning: aztec.santafe.edu: rms set sender to rms@aztec using -f
Original-To: burton@openprivacy.org
In-Reply-To: <87sn23v2nt.fsf@openprivacy.org> (burton@openprivacy.org)
Errors-To: emacs-devel-admin@gnu.org
X-BeenThere: emacs-devel@gnu.org
X-Mailman-Version: 2.0.11
Precedence: bulk
List-Help: <mailto:emacs-devel-request@gnu.org?subject=help>
List-Post: <mailto:emacs-devel@gnu.org>
List-Subscribe: <http://mail.gnu.org/mailman/listinfo/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=subscribe>
List-Id: Emacs development discussions. <emacs-devel.gnu.org>
List-Unsubscribe: <http://mail.gnu.org/mailman/listinfo/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <http://mail.gnu.org/pipermail/emacs-devel/>
Xref: main.gmane.org gmane.emacs.devel:6146
X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:6146

    > Not exactly: it also makes each GC significantly slower (in my experience).

Part of GC spends time on garbage, but most of GC spends its time only
on live data.  So the time should be determined more by the amount of
live data than by the amount of garbage, unless there is lots and lots
of garbage.  Until the gc-cons-threshold becomes a few times the total
amount of live data, I'd expect increases in it not to cause any
slowdown.

Perhaps gc-cons-threshold should be a float which expresses a fraction
of the total amount of live data as of the last GC.