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: Sun, 12 Mar 2023 16:40:05 +0200 Message-ID: <831qluuj7e.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19040"; mail-complaints-to="usenet@ciao.gmane.io" Cc: arne_bab@web.de, spacibba@aol.com, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Mar 12 15:41:10 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 1pbMsn-0004lK-6f for ged-emacs-devel@m.gmane-mx.org; Sun, 12 Mar 2023 15:41:09 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pbMrz-0001sQ-FT; Sun, 12 Mar 2023 10:40:19 -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 1pbMry-0001sE-8c for emacs-devel@gnu.org; Sun, 12 Mar 2023 10:40:18 -0400 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 1pbMrx-00011U-Py; Sun, 12 Mar 2023 10:40:17 -0400 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=2bEmdyckCvOPjOlkpxT+OJRW0/QMyIJ1yI+h9Sbj92U=; b=NIvvMFBllVXC pIUjvYdjbac/vuog2EZUQmFQ83lK1VYer45vUjXFgu7G5570iebQm7YH4ZlOGttPUOAv4mrcSTiKE nYrTieDstd3/53OfFh0qrwhwCfS9aKR1KnwiuJNjiOxtJXKXWehCaDYpgLT2VVBpB63tU0VzmdWAo h8QJCp5Fnny4E+VWpuM75GHSbADRIENWam9d9wkM9SgTEXeXhJnc4pNawtb700cEL9hq9IJr9XhXX 5Q00Md1FLz55ey34TvsLRcBThsqpsRBktM5NZNPB1zSJgYwJB8mbn1/EUMtPSJ53QbH2Om/4Udkx0 eEElZZhIWsZBusGyEDVE+g==; 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 1pbMrx-0005kM-6h; Sun, 12 Mar 2023 10:40:17 -0400 In-Reply-To: <871qluuk3y.fsf@localhost> (message from Ihor Radchenko on Sun, 12 Mar 2023 14:20:33 +0000) 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:304370 Archived-At: > From: Ihor Radchenko > Cc: arne_bab@web.de, spacibba@aol.com, emacs-devel@gnu.org > Date: Sun, 12 Mar 2023 14:20:33 +0000 > > > I'm talking about basis for the 0.7% figure. > > 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. > 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. > 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. > > 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. > - Emacs uptime 2 days 5 hours 21 minutes -> 1 GC per 10 minutes I'm running with gc-cons-threshold of 1.8 MiB, and get about 1 GC per minute. (Actually, it's about twice that, because Emacs stays up at night, but does nothing.) > - memory-limit 6,518,516, stable ??? That's 6 GiB. Didn't you say your memory footprint stabilizes at 1 GiB? 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.