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: Mon, 13 Mar 2023 15:01:47 +0000 Message-ID: <873568d7ac.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> <877cvmumjq.fsf@localhost> <83356aukkh.fsf@gnu.org> <87y1o2t45i.fsf@localhost> <83wn3mt33c.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="17447"; 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 Mon Mar 13 16:01:03 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 1pbjfa-0004KL-PS for ged-emacs-devel@m.gmane-mx.org; Mon, 13 Mar 2023 16:01:02 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pbjex-0006Bq-PI; Mon, 13 Mar 2023 11:00:23 -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 1pbjew-0006BE-9H for emacs-devel@gnu.org; Mon, 13 Mar 2023 11:00:22 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pbjet-00062y-85 for emacs-devel@gnu.org; Mon, 13 Mar 2023 11:00:22 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 22211240467 for ; Mon, 13 Mar 2023 16:00:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1678719617; bh=1wwJJDnekmhktiQ3CXo/N+LKMRzifF//Ns75NWNg5HI=; h=From:To:Cc:Subject:Date:From; b=c3jrJySSRmBITFo33qlQkWVs46+uytTsQg4kvG6Z/MVzp2p+qAD6VKxXGIFt5+a/U ee8yllB+AbahQa8y7cIJfKiLW+Ege69VhdxFQtiYjWL5a/d+jCDudw/xKihAnWG/gf F5jKmH5RrRQuh5TV2r9meEdumXf8ICG3vE4ZxwuuZaZg5O8quKAv+8nkdt/gbNvlMY 8RZKhSjlIapcZweuTANxm8yVlNnkU0pvvZHRfZSG4Fn3oxz57+8EDfD3Nec55AFzoO BI2xnQ0bCIOdKLrhGerFGHG6LDeiaucuW/mTWArMU4Xo11pOVC9ImeS9zOVhnfQcHm oBq8Xx8cQYe9w== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Pb0FX3kmtz6tn7; Mon, 13 Mar 2023 16:00:16 +0100 (CET) In-Reply-To: <83wn3mt33c.fsf@gnu.org> Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.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=unavailable 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:304396 Archived-At: Eli Zaretskii writes: >> I meant that as long as gc-cons-threshold is much lower (10x or so) than >> heap size (Lisp object part), we do not need to worry about (1). Only >> (2) remains a concern. > > Your gc-cons-threshold is 250 MiB. If it's below 0.1 of the size of > Lisp data, does that mean you 2.5 GiB or more of Lisp data in your > sessions? That's a lot. I have less than 300 MiB, for comparison, > and this is a session that runs for 25 days non-stop, and has a > 520 MiB memory footprint. I said nothing about my settings. Because my settings are tailored to my usage. In this discussion, I am trying to deduce something reasonable based on logic, not just on what works for me personally. >> 10% also means that 800k gc-cons-threshold does not matter much even >> with emacs -Q -- it uses over 8Mb memory and thus gc-cons-percentage >> should dominate the GC, AFAIU. > > How did you measure those 8Mb? On my system, memory-report in > "emacs -Q" shows less than 2 MiB in object memory. emacs -Q M-x memory-report on my side gives Estimated Emacs Memory Usage 3.2 MiB Overall Object Memory Usage 2.2 MiB Memory Used By Global Variables 1.3 MiB Memory Used By Symbol Plists 334 KiB Reserved (But Unused) Object Memory 66 KiB Total Image Cache Size 21 KiB Total Buffer Memory Usage A sum of all the above is 7.121, which I rounded up. >> Note that my proposed 100Mb gc-cons-threshold limit will correspond to >> 1Gb live Lisp objects. For reference, this is what I have now (I got the >> data using memory-usage package): >> >> Total in lisp objects: 1.33GB (live 1.18GB, dead 157MB) > > We need to align and calibrate our measurement means: what does > memory-report tell about object memory in that session? 1.18 GiB > sounds a lot. Unfortunately, memory-report is not usable in my sessions. M-x memory-report takes 10+ minutes and then fails with max nesting error for me. That's why I use memory-usage third-party package, which produces some info and does it in reasonable time. >> > Actually, Emacs tries very hard to avoid fragmentation. That's why it >> > compacts buffers, and that's why it can relocate buffer text and >> > string data. >> >> Indeed. But despite all of the best efforts, fragmentation increases if >> we delay GCs, right? > > Not IME, no. That's why the memory footprint of a typical > long-running session levels out. Then what is the mechanism of gc-cons-threshold affecting the Emacs memory footprint? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at