From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Re: Indentation and gc Date: Sat, 11 Mar 2023 13:10:35 +0000 Message-ID: <87edpvwi0k.fsf@localhost> References: <20230310110747.4hytasakomvdyf7i.ref@Ergus> <20230310110747.4hytasakomvdyf7i@Ergus> <87a60k657y.fsf@web.de> <838rg4zmg9.fsf@gnu.org> <87ttyrwobj.fsf@localhost> <83mt4jwjjj.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8855"; mail-complaints-to="usenet@ciao.gmane.io" Cc: arne_bab@web.de, spacibba@aol.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Mar 11 14:09:36 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 1payye-00028G-0c for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Mar 2023 14:09:36 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1payyF-000335-OR; Sat, 11 Mar 2023 08:09:11 -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 1payyD-0002yD-UH for emacs-devel@gnu.org; Sat, 11 Mar 2023 08:09:10 -0500 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1payyB-0002aa-A2 for emacs-devel@gnu.org; Sat, 11 Mar 2023 08:09:09 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 7CF602401AE for ; Sat, 11 Mar 2023 14:09:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1678540145; bh=4skhICMAmSNIZWn0JNcDrurU4KikLJYQcokm3qlmv8g=; h=From:To:Cc:Subject:Date:From; b=Akg2srlQ91Ks6VLpSTZEnxa9qeXDRcr2lIBVnNcNHpv+WGwkUH++M9/77Kcq9EbQn l56CMb8TsfuU5RhuXBaKfyuTD9sgZYhJfGeZKxzvenbvxnYvFlPDIwKzsh8t4Nl4yb IIjMQB5qS6W7FbLOdXpmkGyekOFeRxXb7UN1Ij9k1dOXwsq3zjirzwBzfqxZtWm+nm SaaKn7TQvY2Egx8H2rsiHLFq5an0fUJxt7dR6HxrmBMaLpVKC5Gc/vWsCjAf8XcPSw kgCeyQNwcUNhzdaEub+v8IZ3KtGzLitroo4zpTx6T8kIcaYL8ec5E6TFRCQRTKLKlj HlyQWq9hQI10Q== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4PYjt76Ndrz9rxF; Sat, 11 Mar 2023 14:09:03 +0100 (CET) In-Reply-To: <83mt4jwjjj.fsf@gnu.org> Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:304307 Archived-At: Eli Zaretskii writes: >> > This can only be done around specific portions of code known in >> > advance to be long and GC-intensive. I don't think this kind of >> > technique can be used in the situation described by the OP. >> >> May it be done when loading init.el and early-init.el? > > See my response, where I explain that it is not easy, AFAIU. Are you referring to https://yhetil.org/emacs-devel/83fsabyb41.fsf@gnu.org ? 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. Emacs may start exceeding memory limits just from loading an extra package of something along that lines. Memory-constrained users probably need to carefully search for a balance anyway. What about setting gc-cons-threshold (and leaving gc-cons-percentage intact) as a fraction of the available memory as returned by `memory-info'? 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. The default may even disable this whole thing when the available system memory is small. >> As for "known in advance", may Emacs keep track of how many GCs are >> triggered by user commands and then adjust GC dynamically? > > Adjust how? If you mean enlarge under some conditions, then please > tell: > > . what are those conditions? AFAIR, being too smart here does not work well. I experimented with similar ideas in the past (by modifying gcmh package). 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'. Upon finishing the command, GC thresholds are lowered back to standard. > . should the threshold also go down under some other conditions, and > if so, how? I do not think that the threshold should be lowered. This increased value should not affect many commands to start with - just the most resource-intensive ones. > . how to determine the ceiling for increasing the threshold? That's a good question. 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. 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. Of course, the experiment should happen on master. Not on the release branch. Maybe with extra statistics collected after the release in Emacs survey. I tried something similar in Org. See https://list.orgmode.org/m2y1p22nfn.fsf@ioa48nv.localdomain/T/#t -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at