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: Sun, 12 Mar 2023 13:27:53 +0000 Message-ID: <877cvmumjq.fsf@localhost> 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> <83fsabyb41.fsf@gnu.org> <87mt4jtpqf.fsf@web.de> <83ilf7wi48.fsf@gnu.org> <878rg3wh2f.fsf@localhost> <87a60jtg0z.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34762"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , 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 Sun Mar 12 14:27:15 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 1pbLjG-0008i3-5F for ged-emacs-devel@m.gmane-mx.org; Sun, 12 Mar 2023 14:27:14 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pbLiY-0005KV-Oy; Sun, 12 Mar 2023 09:26:30 -0400 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 1pbLiX-0005Jx-6e for emacs-devel@gnu.org; Sun, 12 Mar 2023 09:26:29 -0400 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 1pbLiU-0007gF-EI for emacs-devel@gnu.org; Sun, 12 Mar 2023 09:26:28 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 120E324008A for ; Sun, 12 Mar 2023 14:26:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1678627584; bh=qoLJEg6r1pecl5MHGR77Zfi0vf4hRufG0x3xKNokJEM=; h=From:To:Cc:Subject:Date:From; b=XBiKNxLw/JdRikq8SrEM+G9vKo8G1OlM0LBf5Ii4rTnKG439S0aXROWqSG67kfmlz E3n/WLB5iMap5e3H4v+nd3unL0mQTivbevg085dVToTQtwpmVTOqiGt6G3GRAxYzNM 6ONi9T77XbYjZux6I5w5WDUq6xUaeTC6D1rkMZNniYHZlkSnGN2/mnCXrB9SKORRBX 3ZTlPxaNDGV3imioYn3hq6VoQxbcHwZ+PwSxtl6jiHaNZPU4mBBYbYJULdlVFl1L6T +uPcrnhy5ksiuWBx6ZceCBjcPFSz0i//0fhu1NfLZ+JOyam1clufSBybAhubEVpFj2 oFrnll8KYcN7Q== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4PZLCf57mpz9rxM; Sun, 12 Mar 2023 14:26:22 +0100 (CET) In-Reply-To: <87a60jtg0z.fsf@web.de> 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:304367 Archived-At: "Dr. Arne Babenhauserheide" writes: >> What is the smallest practical free RAM available to Emacs on low-end sy= stems? >> We can take that value and then use 800kb/min free RAM in the wild and >> the base threshold. On system with larger RAM the threshold will scale. > > It=E2=80=99s not that simple =E2=80=94 at least outside loading the init = file. If you > increase this fraction, then GC pauses will be longer and Emacs may feel > jittery or even become unresponsive for some time. > > So there should likely be also a hard upper limit to ensure that the > pauses are unnoticeable. Well. I do realize that there should be a limit, which is why I put it as 100Mb. Strictly speaking, GC pauses scale with heap size. Increasing GC threshold will have two effects on the heap size: (1) thresholds lager than normal heap size will dominate the GC time - Emacs will need to traverse all the newly added data to be GCed; (2) too large thresholds will cause heap fragmentation, also increasing the GC times as the heap will expand. I think that (2) is the most important factor for real world scenarios (unless we set the threshold insanely high, higher than memory usage in "heavy" Emacs sessions). Emacs' default gives some lower safe bound on the threshold - it is `gc-cons-percentage', defaulting to 1% of the heap size. However, being safe is unfortunately not enough - apparently 1% heap size is too less in real world scenarios when 1% is routinely and frequently allocated, triggering GC rescans too many times. Especially so, when loading init.el. The heap size is yet smaller than normal and GC is triggered even more frequently. AFAIU, routine throw-away memory allocation in Emacs is not directly correlated with the memory usage - it rather depends on the usage patterns and the packages being used. For example, it takes about 10 complex helm searches for me to trigger my 250Mb threshold - 25Mb per helm command. The GC frequency often depends on how heavily I use helm completion. To get some idea about the impact of gc-cons-threshold on memory fragmentation, I compared the output of `memory-limit' with 250Mb vs. default 800kb threshold: 250Mb threshold - 689520 kb memory 800kb threshold - 531548 kb memory The memory usage is clearly increased, but not catastrophically, despite using rather large threshold. Of course, it is just init.el, which is loaded once. Memory fragmentation as a result of routine Emacs usage may cause more significant memory usage increase. Not multiple times though (not even twice in my setup). >From the above, I expect the increase of gc-cons-threshold 100x to impact the memory dis-proportionally - between as little as 1.1x and 2x. As long as gc-cons-threshold is significantly (~10x) lower than normal Emacs heap size, I expect the GC frequency to scale down the same 100x at very little cost. For me, Emacs memory usage typically settles around 1Gb, which is why I chose 100Mb as an upper limit (1Gb/10). If we want to be even more safe, as I proposed, we can only increase the gc-cons-threshold when loading init.el and possibly for certain, most GC-heavy commands. This will minimize the impact of memory fragmentation - only a small set of commands (having more regular memory allocation pattern) will cause the fragmentation. --=20 Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at