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 19:25:05 +0200 Message-ID: <83wn3nurny.fsf@gnu.org> References: <20230310110747.4hytasakomvdyf7i.ref@Ergus> <20230310110747.4hytasakomvdyf7i@Ergus> <87a60k657y.fsf@web.de> <838rg4zmg9.fsf@gnu.org> <87ttyrwobj.fsf@localhost> <20230311111730.fatow74xnbel7t3f@Ergus> <83o7ozwju8.fsf@gnu.org> <87jzznwjh3.fsf@localhost> <83jzznwjeh.fsf@gnu.org> <87fsabwirg.fsf@localhost> <83h6urwhu0.fsf@gnu.org> <875yb7wgpd.fsf@localhost> <83bkkzwgcp.fsf@gnu.org> <87y1o3v1fr.fsf@localhost> <838rg3wf7k.fsf@gnu.org> <87v8j7v0a4.fsf@localhost> <835yb7were.fsf@gnu.org> <87r0tvuzpl.fsf@localhost> <834jqrwbgu.fsf@gnu.org> <87jzzn9pti.fsf@no.lan> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3867"; mail-complaints-to="usenet@ciao.gmane.io" Cc: yantar92@posteo.net, spacibba@aol.com, arne_bab@web.de, emacs-devel@gnu.org To: Gregor Zattler Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Mar 11 18:26:05 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 1pb2yr-0000o8-JP for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Mar 2023 18:26:05 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pb2yF-0000dU-3E; Sat, 11 Mar 2023 12:25: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 1pb2yD-0000dM-6X for emacs-devel@gnu.org; Sat, 11 Mar 2023 12:25: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 1pb2yC-0003In-B3; Sat, 11 Mar 2023 12:25:24 -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=CjYs9mp5sSJqeaJTmhfuLKWlYkZB5gPVdms8a4FfsgM=; b=JV35AOeI/iY0 SbiFsElGM49VbrTkuN0gT5wrnKPZAwZ1yefN0+8GwImcrp90PHYjIs6Dj55EUHoRbKcm85H4WmSTP c8nYpFVbAGNTz1++J1nZkbUTtvaW0+pkGK7AAodzU9n+8mBmy0NWA6k5lAPUqLYJRywAdnj+e6ig+ D8fvhsGNN5pKtBCh6euDMLyI+OCEdpZ7qupgi5LfnoSugLRJ1NXeV3kmegbRch/nXi20innO1i7Hr qJIr59kdtNlWICCtIJVoy/ZUO9q1j10Mub5yXXeFQsLC5Hk8tjRLIDaQfBHZMyAMiJT/Nf2K6vkyY IXIHDV3f1mMGbK88IzkBMg==; 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 1pb2y8-0001zM-JK; Sat, 11 Mar 2023 12:25:23 -0500 In-Reply-To: <87jzzn9pti.fsf@no.lan> (message from Gregor Zattler on Sat, 11 Mar 2023 18:10:33 +0100) 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:304330 Archived-At: > From: Gregor Zattler > Cc: spacibba@aol.com, arne_bab@web.de, emacs-devel@gnu.org > Date: Sat, 11 Mar 2023 18:10:33 +0100 > > > Again, you are reasoning about the value as if it were related to the > > maximum memory footprint Emacs could have. But in fact, it is related > > only to the _increment_ of memory Emacs can have before it should stop > > and consider how much of that is garbage. > > But isn't that the very reason, why Ihors gc-cons-threshold > calculation in mid:878rg3wh2f.fsf@localhost is on the > save side memory wise? Because it's a fraction of emacs > overall memory consumption anyway but scaled regarding > the total amount of memory? No. The limitation on the _increment_ should have nothing to do with how much memory is already consumed or how much total memory is available on the system. Imagine an Emacs with N MiB of memory footprint on a system that has N+1 MiB of memory available. IOW, what matters is how much is _left_, not how much is already used or totally available. > To me the problem with big gc-cons-threshold even on systems > which are even bigger on RAM is that the (rare) garbage > collection the takes much more time and an uneducated > user might think Emacs hangs. That is another downside of large GC threshold, yes. Which again tells us that making the threshold grow linearly with the available total VM is not TRT, there should be a hard limit that is not just arbitrary, but related to the time it takes to perform GC on that many objects. > I played a lot recently witch gc-cons-threshold settings due > to Emacs being too sluggish with my old ones. Now I: > > - set gc-cons-threshold very high at the beginning of > startup (* 4096 40960) > - set it lower at the end of startup > (/ (* 4096 4096) 1) > - use gcmh with this value > - set it very high when entering the mini-buffer and > lower again when exiting it > - force a gc when frame loses focs > > The result is that with emacs-uptime being 7 hours, 21 > minutes (and plenty of time away from the computer) I > have 103 messages regarding Garbage collection with > accompanied times for them in my message buffer. > > Some statistics: > > Minimal number 0.000 seconds > Maximal number 2.603 seconds > Sum 65.896 seconds > Average 0.63976699029126213592 seconds > Median 0.612 seconds > Variance 0.06970711075501932322 > Standard deviation 0.26402104225803541665 > > Actually 0.6 seconds are already rather long I think. > But it's much better than before (on a ca. 9 years old > x240 with 8GB RAM) The above means you tuned the threshold to your system and personal needs. Which is what everyone should do if they are bothered by frequent GC cycles and too long run times of some Lisp programs they care about. > Therefore I think some auto-adjustment of > gc-cons-threshold would be nice, which would try to > optimize for low number of garbage collection and short > times of actual gc runs. "Therefore"? how does this follow from what you did? Your tuning is static and is appropriate for your usage. Others will most probably come up with different numbers using the same procedure. How do you propose to make this into some kind of auto-adjustment, when how much garbage is generated and the amount of slowdown this incurs depends on the Lisp programs that typically run?