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: Wed, 15 Mar 2023 16:20:57 +0200 Message-ID: <83y1nyqenq.fsf@gnu.org> References: <20230310110747.4hytasakomvdyf7i.ref@Ergus> <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> <83v8j6t2ib.fsf@gnu.org> <87zg8gbsch.fsf@localhost> <838rg0u0fd.fsf@gnu.org> <87wn3ky7rz.fsf@localhost> <831qlstwoi.fsf@gnu.org> <87r0tsy1c4.fsf@localhost> <83wn3jseyt.fsf@gnu.org> <87mt4eqpfd.fsf@localhost> <83zg8eqinu.fsf@gnu.org> <87h6umqig6.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2414"; 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 Wed Mar 15 15:22: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 1pcS0t-0000I9-Tn for ged-emacs-devel@m.gmane-mx.org; Wed, 15 Mar 2023 15:22:00 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pcS0D-0006La-8t; Wed, 15 Mar 2023 10:21:17 -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 1pcS0C-0006LC-4V for emacs-devel@gnu.org; Wed, 15 Mar 2023 10:21:16 -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 1pcS0B-0004lO-HF; Wed, 15 Mar 2023 10:21:15 -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=I0B+rvrTtZLm9kXmIR5/1ILs2jL4GxIvZJ4JflIcY7s=; b=MSN9SMdYe765 ecgggGDf6ATeDATSB++5y72AoZE1VB77k9duJg4oBXG7KIHNjj9MN6Tr39OGRUBnSLWNlCBYZ5PWS h9/0gZHoBYYbW7GKHDiX025038mKl8y8mT6+GrXGh6ClWZB0KEnFw/+xpz8pg7x6vSxTd6zyIeBtt F/6sYx6PnDPsgjaClJwAs95u9jWOzPSieagFvvpsrcYBDLRc1pJFsA/YO6z/LJOnBpAG6tMZTILa6 R5cGGr3LGm2JxkGGTiG/UiyAThMIuKOrOZjBMTVx5OyuWPDJM1i+47T4PGZXDHuQSSLmLm7cB6hZV ym71eHA5bZ7gdYkLlahtBA==; 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 1pcRzx-0000gy-8g; Wed, 15 Mar 2023 10:21:15 -0400 In-Reply-To: <87h6umqig6.fsf@localhost> (message from Ihor Radchenko on Wed, 15 Mar 2023 12:59:05 +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:304498 Archived-At: > From: Ihor Radchenko > Cc: arne_bab@web.de, spacibba@aol.com, emacs-devel@gnu.org > Date: Wed, 15 Mar 2023 12:59:05 +0000 > > Eli Zaretskii writes: > > >> Then, from what I can read, it does not look like VIRT truly represents > >> how much memory Emacs is going to use. It is safe to assume that only a > >> fraction of VIRT will be used in practice. > > > > I don't think I follow your logic. > > > > Emacs can have more memory in use than the physically installed > > amount, it just means each GC will be painfully slow, because it will > > need to swap in parts of memory and swap out other parts. In theory, > > Emacs can use all the VM there is, minus what other processes and the > > OS use. > > > > If your bother is about the "reserved" part, that is not supposed to > > be large, but maybe glibc has its own ideas about that, because your > > report about VIRT vs RES surprised me. > > Then what should we collect from user session? > memory-limit represents VIRT, but it does not look terribly useful. > > What exactly should we use as a metric for the effects of > gc-cons-threshold changes? I guess the output of memory-info should be good, in addition to memory-limit. I do think memory-limit is useful, albeit we should take it with a grain of salt sometimes. A too-large difference between memory-limit and the resident set size is perhaps already an important indication of some trouble, although I'd like to see more examples to make up my mind about that. But that's the possible downside of higher GC thresholds; other important indications are the time spent in GC and the average duration of a GC cycle.