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 15:38:09 +0200 Message-ID: <83edpvwgqm.fsf@gnu.org> References: <20230310110747.4hytasakomvdyf7i.ref@Ergus> <20230310110747.4hytasakomvdyf7i@Ergus> <87a60k657y.fsf@web.de> <838rg4zmg9.fsf@gnu.org> <87ttyrwobj.fsf@localhost> <83mt4jwjjj.fsf@gnu.org> <87edpvwi0k.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26683"; mail-complaints-to="usenet@ciao.gmane.io" Cc: arne_bab@web.de, spacibba@aol.com, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Mar 11 14:38:43 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 1pazQo-0006km-Sh for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Mar 2023 14:38:42 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pazQZ-0003Ka-TK; Sat, 11 Mar 2023 08:38:27 -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 1pazQX-0003KS-Fi for emacs-devel@gnu.org; Sat, 11 Mar 2023 08:38:25 -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 1pazQX-00086q-6E; Sat, 11 Mar 2023 08:38:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=ACe7sSsPHHldAxjvoMNZkGgnRhLkevmgycYaxe1uwcs=; b=iKIjDX6ne8Mk jPu+is1iD8ztYf9cB7kopyeQIxucD7zYz14ylfHQctzdaXxHmhEZL6gPcQl6lvlBDiH8VlZ75amkm em3/6cSzAOv6JJI20du3kTXpEGskfSipfwUXk3tS7ewRCWVm36B8v844SRvCUt5p5EfBoeM7cPywQ 4fthWXwm1jBs8C91QUoiAN+hMlOpBquSHu2WxFTUrJx/0RgdEyFZnJFZY0puVywKuygN9f9DWvRcC yIK9dl2RoenEihUmVmn1b2KBVsPu0a3dwun0vVS+dwZb7Pd0BNdAA3Tl5MWg1W6JaBYD8b9rpGTox vsWp5Uc3/164RGzj+Zxe+g==; 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 1pazQW-0002xs-LS; Sat, 11 Mar 2023 08:38:24 -0500 In-Reply-To: <87edpvwi0k.fsf@localhost> (message from Ihor Radchenko on Sat, 11 Mar 2023 13:10:35 +0000) 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:304311 Archived-At: > From: Ihor Radchenko > Cc: arne_bab@web.de, spacibba@aol.com, emacs-devel@gnu.org > Date: Sat, 11 Mar 2023 13:10:35 +0000 > > If so, as you said, there is no guarantee that the threshold is never > exceeded. So, running Emacs when the available memory is extremely close > to the heap size is not safe anyway. What do you mean by "heap size" here? We aren't talking about the heap, we are talking about the VM size of the system, vs how much of that is typically consumed by programs. The answer depends on the system and on the usage patterns. > Emacs may start exceeding memory limits just from loading an extra > package of something along that lines. It depends how large is the memory consumption of that package and how much memory the system has. > Memory-constrained users probably need to carefully search for a balance > anyway. The current GC threshold is unlikely to cause problems on systems with even very little memory. Emacs itself needs around 15 to 20 MiB even when started with -Q, so if the system is capable of running Emacs, it should be able to cope with relatively minor increases of the memory footprint, such as what the default GC threshold produces. You suggest increasing the threshold significantly, which could make the danger of OOM much higher, especially on memory-challenged systems. > What about setting gc-cons-threshold (and leaving gc-cons-percentage > intact) as a fraction of the available memory as returned by > `memory-info'? See my other message a few minutes ago, where I already responded to a similar proposal. > At least, when loading init.el. This can be a custom > setting like `gc-cons-threshold-init' that may either be nil (fall back > to `gc-cons-threshold'), an integer (bytes), or a float representing a > fraction of free memory. The default can be a fraction of free memory, > if memory info is available for a given system. Which fraction? If we leave determination of the fraction to the user, we might as well not provide any new defcustoms at all, since the existing variables cover that, and you are saying that everyone increases the threshold to most-positive-fixnum anyway. > I'd introduce a custom setting `gc-cons-percentage-2/`gc-cons-threshold-2' > that will define an alternative (larger) GC threshold that is used for a > command if the number of GCs exceeds `gcs-done-threshold'. How is this different from what we already have? > Upon finishing the command, GC thresholds are lowered back to standard. Why only "command"? What about stuff that runs from post-command-hook or from timers or from process filters? Some of them could be as performance critical as an interactive command, no? > > . how to determine the ceiling for increasing the threshold? > > That's a good question. That's the main question, from my POV. Without a good answer, we don't have any reason to introduce any new features related to this. > I'd start with trying 5-10x normal value of gc-cons-percentage for > commands that spend more than 0.1-0.2 sec (noticeable delay) in more > than a single GC. Again: why only commands? And how to know which ones will take more that the times you consider as significant? (And why should everyone use these times, which appear to be quite low?) > Then, I'd add some code that will collect statistics of the impact > of the new setting. After some time, I will ask users to share the > statistics in one of the Emacs surveys or just by asking on mailing > list. Then we should start with just this, and revisit the issue only after we have some significant statistics. Note that users will have to tell much more than just threshold numbers: they will need to tell how much memory they have and also the memory footprints of the programs running on their systems.