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 17:26:04 +0200 Message-ID: <83v8j6t2ib.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> <831qluuj7e.fsf@gnu.org> <87v8j6t3i9.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22652"; 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 16:27:02 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 1pbNb7-0005Nm-AD for ged-emacs-devel@m.gmane-mx.org; Sun, 12 Mar 2023 16:26:57 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pbNaV-0003vb-IE; Sun, 12 Mar 2023 11:26: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 1pbNaU-0003vS-3M for emacs-devel@gnu.org; Sun, 12 Mar 2023 11:26: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 1pbNaT-0007Pi-ND; Sun, 12 Mar 2023 11:26: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=PbgSCidGQY9n/8se9Gp7i/bOIc7qEUDo03nkY6B1xfw=; b=fuqn3Q8Pqf+d jloPgcUoJj8Hl5TvJPd/EfNwE+PupdJE6Io2m0GsUpDp2x9Up7aytI5web6U3Tkl8x4DU/jCEWerF oA4fbpsc+l4CZOkFgbPUcCTr5U8w+xJNhcUSNXjdffpW/2w7iWX+eAD2IKuJ8V8V6RpJPXKqtQDh6 xs/6UFOG/vrUcZuJXFk8mxIkOUcdTdTk6vG1PFYt9wxEkRAOLPRDh8g5LaTCTiI10WIzWhz5Ca6Fj DFpvZ4DZDECSCOZP8LimjWFOxG1xSehzusk9gdIERrLZkD7YYHMJRChsdzA98D519oOj5pct7FN3+ +f/20fMwX59RQd1SILo7YA==; 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 1pbNaT-0005aL-1b; Sun, 12 Mar 2023 11:26:17 -0400 In-Reply-To: <87v8j6t3i9.fsf@localhost> (message from Ihor Radchenko on Sun, 12 Mar 2023 15:04:30 +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:304376 Archived-At: > From: Ihor Radchenko > Cc: arne_bab@web.de, spacibba@aol.com, emacs-devel@gnu.org > Date: Sun, 12 Mar 2023 15:04:30 +0000 > > > 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. We should ask them to report statistics after running a session for enough time. What exactly qualifies as "enough time" depends on the usage patterns: there are people, like me, who run a single session for weeks on end, and there are others who start a new session every day or even more frequently. What is interesting is the statistics near the end of the session. Statistics from loading init.el is much less interesting, mainly because reducing GC impact during such short intervals is easy and well-understood. We could collect such statistics as well, but it is not the main goal from where I stand. > 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. A single very long GC will be annoying even if it happens rarely. So I don't agree the frequency of GCs is so much more important than the time it takes to perform a GC. > >> - 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. If the Emacs memory usage in system monitor is 1.7 Gib, how come memory-limit says it's 6.5 GiB? > Shall we ask about benchmarking init.el with different gc-cons-threshold > values as a start? See above: I'm more interested in statistics of the session than in statistics of the initial load.