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 15:04:30 +0000 Message-ID: <87v8j6t3i9.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> <83cz5fwggd.fsf@gnu.org> <871qlvwg1s.fsf@localhost> <83a60jwf9l.fsf@gnu.org> <871qluuk3y.fsf@localhost> <831qluuj7e.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="19276"; 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 Sun Mar 12 16:04:00 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 1pbNEt-0004kP-JM for ged-emacs-devel@m.gmane-mx.org; Sun, 12 Mar 2023 16:03:59 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pbNE7-0007VN-Cs; Sun, 12 Mar 2023 11:03:12 -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 1pbNE2-0007VC-LZ for emacs-devel@gnu.org; Sun, 12 Mar 2023 11:03:06 -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 1pbNE0-0004Et-7W for emacs-devel@gnu.org; Sun, 12 Mar 2023 11:03:06 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 55FCC240033 for ; Sun, 12 Mar 2023 16:03:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1678633382; bh=XRtCpvImamN6wnWvkcOTRtLsxtuoXLXsAKoZlK2GdiM=; h=From:To:Cc:Subject:Date:From; b=PQH+rSgxGUVxo86HWDsFHOxcDiPEg9NgGv91SYkaYeTdCfyqiDxC4UIqh2tIgNmhC cscTUBEEbUxPbspX0MZ57oKUAR3zbUPqEBpcG6+l6RgBm8aMxe1NVle9rQBpNFxDvj NaPLfeQt/+5k7C+d+iQuHVM3dOtP2ob6dcmT7YEK/hdPo0QXeLrE3yXtuPix39GAPI OYlpEGaQP6vSEhhHcPKLdgqqZzu0h8bpw/0FdUZqXlMTXjiQf170YJIkaux8ZMSQXZ twhqacYTJgj7YS4JSqHUDlolSWYgo4g7ZeobDH7MQt3DJAcOkgewWMtVl9+4Iav3O4 7P6VOqgVzK34A== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4PZNM85Nj6z6tpD; Sun, 12 Mar 2023 16:03:00 +0100 (CET) In-Reply-To: <831qluuj7e.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=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:304374 Archived-At: Eli Zaretskii writes: >> I used 0.7%*RAM because total RAM is the only reasonable metrics. What >> else can we use to avoid memory over-consumption on low-end machines? > > It could be the amount of VM on low-memory machines, but something > else on high-memory machines. No one said it has to be derived from > the total VM on both systems with 2 GiB and systems with 128 GiB. For high-memory machines, the aim is using the limit (100Mb, in what I proposed), or something close to it. I see no point trying to be precise here - even what I propose is better when memory is not low, if we aim for increased, yet safe gc-cons-threshold. >> Of course, I used implicit assumption that memory usage will scale with >> gc-cons-threshold linearly. IMHO, it is a safe assumption - the real >> memory usage increase is slower than linear. For example, see my Emacs >> loading data for different threshold values: > > We are talking about changing the threshold for the session itself, > not just for the initial load. So the statistics of the initial load > is not what is needed. Session statistics is much harder to gather. It is more realistic to ask people about benchmarking their init.el if we want to be serious about bumping gc-cons-threshold. At least, we can then get a good limit for init.el. >> The 0.7% is to ensure safe 800kb lower bound on low-end computers. > > I don't see why it would be the value we need to adhere to. That it's > the current default doesn't make it sacred, and using it as basis for > relative figures such as 0.7% has no real basis. We do not have to adhere to this value. But we know for sure that it is 100% safe. And we probably cannot easily get the data from low-end machines - much fewer users are using those. So, instead of arguing about lower limit as well, let's just use the safe one. We can always bump it later, if we wish to bother. >> > Anyway, how about if you try running with the threshold you think we >> > should adopt, and report back after a month or so, say? >> >> I am using 250Mb threshold for the last 3 years or so. >> GCs are sometimes noticeable, but not annoying: >> >> - gc-elapsed 297 sec / gcs-done 290 -> ~1 sec per GC > > IMO, 1 sec per GC is pretty annoying. It's around 0.165 sec in my > production session, and it still quite noticeable. I'd be interested > to hear what others think. 1 sec has little to do with my gc-cons-threshold, I am afraid. It is the combination of packages I use. I have also seen worse memory consumption. In particular, when using spell-fu, which copies over local dictionary in every single buffer. That's why I am seeing reducing the frequency of GCs as more important than trying to reduce GC time, which cannot be even halved easily. >> - memory-limit 6,518,516, stable > > ??? That's 6 GiB. Didn't you say your memory footprint stabilizes at > 1 GiB? memory-limit is a natively compiled function defined in subr.el. Signature (memory-limit) Documentation Return an estimate of Emacs virtual memory usage, divided by 1024. It is different from Lisp object storage size, which is about 1.3Gb. And Emacs memory usage in system monitor is about 1.7Gb. > Anyway, we need such statistics from many people and many different > values of the threshold, and then we will be in a position to decide > on better default values, and perhaps also on some more dynamic > adjustments to it. We are not ready for that yet. Shall we ask about benchmarking init.el with different gc-cons-threshold values as a start? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at