From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Indentation and gc Date: Sat, 11 Mar 2023 09:56:46 +0200 Message-ID: <83fsabyb41.fsf@gnu.org> References: <20230310110747.4hytasakomvdyf7i.ref@Ergus> <20230310110747.4hytasakomvdyf7i@Ergus> <87a60k657y.fsf@web.de> <838rg4zmg9.fsf@gnu.org> <87ttys4dge.fsf@web.de> <83sfebyepp.fsf@gnu.org> <87ttyru4zt.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31287"; mail-complaints-to="usenet@ciao.gmane.io" Cc: spacibba@aol.com, emacs-devel@gnu.org To: "Dr. Arne Babenhauserheide" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Mar 11 08:57:54 2023 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 1pau70-0007tC-Fn for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Mar 2023 08:57:54 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pau6B-0003cm-Jy; Sat, 11 Mar 2023 02:57:03 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pau6A-0003cd-O6 for emacs-devel@gnu.org; Sat, 11 Mar 2023 02:57:02 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pau6A-00054G-3N; Sat, 11 Mar 2023 02:57:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=OAJjNfu/dB8ehMhQK2IO5tzzrlGywKa9SfCbqCQ+5ss=; b=NBXO/RMryqsiJLPLf2Yq nO0rizrpdUExrisOuEy0/GT7EgpGk57Iq72YfgLygXt0vmqosc+VZWyHrhmcByMBiJHRaqfxmawt6 TC1QUYjxhVCYVANFVdJ4T+u9VVrerPR/gGUqtlyn/ATWBKQEZgCHSRDfm32ils1tydPo5ZBIQ3Y2X RNWAuVmgxnn1YY7AQmSUhpTp9YDFOsW5i5fkVA4bZHNb3PokUYGr9lH3UipcPki2K0L9IpQnTl8tF ZXJii4v9Xk1IeGpRviooVZ2HZSc5F+qp+8UIZGI8neYM1QdWE47EbDhaxlfVNtR5fghBK7B7wGPU9 bahH/R9QpEZiig==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pau68-0007tC-Vx; Sat, 11 Mar 2023 02:57:01 -0500 In-Reply-To: <87ttyru4zt.fsf@web.de> (arne_bab@web.de) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:304279 Archived-At: > From: "Dr. Arne Babenhauserheide" > Cc: spacibba@aol.com, emacs-devel@gnu.org > Date: Sat, 11 Mar 2023 07:55:32 +0100 > > Do we have a process to re-evaluate the current settings? Emacs modes > have been getting more complex in the past decades — also because modern > CPUs can execute them — so how can we see whether 800k are still the > right setting for gc-cons-threshold? The "right setting" is very much dependent on the setup and resources on each concrete system. And people tend to run Emacs on some very old systems, as well as on some very new ones. Not sure how to evaluate the default setting in these circumstances. Perhaps the only thing we could do is enlarge the value slightly in Emacs 30. And please keep in mind that the value of the threshold does NOT guarantee that Emacs will call GC as soon as it generated Lisp objects which take that much memory. The test against the threshold is done only when Emacs decides it might be a good time to do a GC, so you could have a Lisp program that runs for prolonged times and generates much more objects than it takes to reach the threshold, before GC happens. It is not very probable to have such programs, but it's definitely possible. E.g., a single make-string call can generate a very large string, which takes much more memory than the threshold, without calling GC. So raising the threshold indirectly raises the probability of having your system run out of memory, even if the threshold value is way below the amount of VM you have. > Another question would be whether enlarging the gc cons threshhold > during reading of the site and init file could be a default. It improves > startup times a lot. See above: to what value will you enlarge it so that it's still safe? The Emacs startup typically does a lot of non-trivial stuff, so could consume large quantities of memory.