From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Garbage collector: is 800kb a good default? Date: Thu, 09 Apr 2020 14:48:57 -0400 Message-ID: References: <83o8s0on41.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="98492"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Eli Zaretskii , emacs-devel To: Dmitrii Korobeinikov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 09 20:50:11 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jMcFe-000PU6-Qg for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Apr 2020 20:50:10 +0200 Original-Received: from localhost ([::1]:54124 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jMcFd-0002NE-SP for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Apr 2020 14:50:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53325) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jMcEe-0001D0-Gj for emacs-devel@gnu.org; Thu, 09 Apr 2020 14:49:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jMcEd-0000rN-Cm for emacs-devel@gnu.org; Thu, 09 Apr 2020 14:49:08 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:48606) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jMcEb-0000qa-1P; Thu, 09 Apr 2020 14:49:05 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 553D7100E11; Thu, 9 Apr 2020 14:49:04 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 4E38A100D4F; Thu, 9 Apr 2020 14:48:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1586458138; bh=jSZKw3ts6F5N9AWH6D2SOYKhq1Z0w/nJQ+cuHFmw6lw=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=aTyX/vhacgtKLLsDabEH3T1pDzDlqzTlYAZlCyx99UUXOOABzDO+gmCr6tfxXh9jt p6W0jhS3O2ZHTU5ki42sX01N2plPTZmZ7RTGHG4vTXYaOBbQhmaNLLii3qtNpil/20 mUM1dq1AmVIObFTe8HonzVlNCdOpX6wxv4PBe1kx3OZOD7kL6Nv2rFJ/HBndR0eavc /xfQXmZnH5/0sB+qYGyZyh1pl5wd2Ne+GbZbEOuNgWsVxWQ0csoHdF2EHiOKJxNLwY 34mZEOL9Zn9HG2+7TPhygkrd5DHLTt6j6O9FJUxXu0w6hjEevTZS4NGSMq+Caj9OrQ mn2i4VcNTNLBQ== Original-Received: from alfajor (unknown [104.247.241.114]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D6D321203B6; Thu, 9 Apr 2020 14:48:57 -0400 (EDT) In-Reply-To: (Dmitrii Korobeinikov's message of "Thu, 9 Apr 2020 19:44:40 +0600") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 132.204.25.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:246722 Archived-At: >> (2) you seem to ignore the increased memory pressure on the rest of >> the system from the growing memory footprint of Emacs. On GNU/Linux, >> Emacs doesn't really return malloc'ed memory to the system, so once >> the memory footprint grows, it more or less stays that way even after GC. I'm personally not too worried about that (I don't run much more than Emacs on my machines), but a high GC threshold tends to lead to a large heap indeed and the problem with it (for me) is that it tends to make the GC yet slower (to which the naive reaction would be to increase the threshold yet further to make GC even less frequent) and it can also slow down the non-GC execution by increasing pressure on the memory hierarchy (using more VM pages and more cache lines, reducing effectiveness of the CPU's prefetcher) because the heap is more sparsely populated. This is not documented with precise measurements, sadly. So it's far from clear how much is too much. Stefan