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: Larger GC thresholds for non-interactive Emacs Date: Sun, 19 Jun 2022 14:11:36 +0300 Message-ID: <83pmj4nc0n.fsf@gnu.org> References: <83y1y2utnd.fsf@gnu.org> <87r13up587.fsf@localhost> <83o7yyur0l.fsf@gnu.org> <87leu2p3nu.fsf@localhost> <83leu2uewn.fsf@gnu.org> <87r13qv701.fsf@localhost> <83bkuursya.fsf@gnu.org> <87h74l9jk8.fsf@localhost> <83bkutqb3z.fsf@gnu.org> <9778F176-E724-4E61-B0FB-327BCDD316C0@acm.org> <87sfo4epeo.fsf@localhost> <87bkurrc5e.fsf@localhost> <87bkur72b7.fsf@gnus.org> <874k0j40e7.fsf@gnus.org> <871qvm16he.fsf@gnus.org> <83a6aanm5j.fsf@gnu.org> <87o7yozzj0.fsf@gnus.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2129"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, yantar92@gmail.com, mattiase@acm.org, theophilusx@gmail.com, rms@gnu.org, acm@muc.de, emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jun 19 13:14:20 2022 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 1o2ssm-0000Mb-5F for ged-emacs-devel@m.gmane-mx.org; Sun, 19 Jun 2022 13:14:20 +0200 Original-Received: from localhost ([::1]:41028 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o2ssi-0001QT-Qf for ged-emacs-devel@m.gmane-mx.org; Sun, 19 Jun 2022 07:14:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34762) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o2sqV-0000NC-Qy for emacs-devel@gnu.org; Sun, 19 Jun 2022 07:11:59 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:55020) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o2sqV-0005XY-Hp; Sun, 19 Jun 2022 07:11:59 -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=SRbeBuMqW73hvIouIGQrDZI69TsvhmOVsVTJn6dmks0=; b=EK91DdE8BkKb EaXQSTwU9nx1FPOrLGOzODcSS4lDjJg6Gq/NsAtRqOavLFeK8k60fUWgZhH4HG5lERL/0GzbO2nGz H/TU+YLM5X1q9kLgg9o9kYNZDnwHO+J/O1wslzMaLKga3Tb5lpD4FYMVkn6YXkXRumsZeHjdNAltH /8dEWeGEl9xnyDlsyue/ZpnQABA9NnVv+zjJfgipSMKq9Neq/UY+AXFHK21wZFNW5BxrQiuT09J4A SRtRBXMAUWja9rqNI+lDv8raYVf1ZVaQ96SbdH2SUyvshKUNeGEguP6C8qGbLeY0/o8W5yKRtQOwQ SSRqcnoYBdLdqFEtvrk/3g==; Original-Received: from [87.69.77.57] (port=2912 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 1o2sqQ-0008Bo-ER; Sun, 19 Jun 2022 07:11:54 -0400 In-Reply-To: <87o7yozzj0.fsf@gnus.org> (message from Lars Ingebrigtsen on Sun, 19 Jun 2022 13:02:59 +0200) 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" Xref: news.gmane.io gmane.emacs.devel:291417 Archived-At: > From: Lars Ingebrigtsen > Cc: monnier@iro.umontreal.ca, yantar92@gmail.com, mattiase@acm.org, > theophilusx@gmail.com, rms@gnu.org, acm@muc.de, emacs-devel@gnu.org > Date: Sun, 19 Jun 2022 13:02:59 +0200 > > Eli Zaretskii writes: > > > AFAIK, that's not really true. We call 'free' and glibc does release > > to the OS when it can. And don't forget that Emacs calls 'malloc' a > > lot not just for conses and other Lisp data. > > Wasn't there a huge discussion about this a couple months ago and the > conclusion was that glibc rarely releases memory back to the OS? That's > why we added `malloc-trim'. Well, "rarely" is not the same as "never". How rare is "rarely" really depends on the specific use patterns, and I don't think we have ever established what kinds of uses cause us to release memory more frequently than others. Maybe it's worth our while to collect some data about this? For example, frequent contributors who tend to run Emacs for many days could perhaps take a snapshot of the total VM of the Emacs process and see how it behaves. Then we'd know how frequently the footprint goes down and by how much. I can tell from my own experience that, when I purge my mail INBOX, typically leaving about 2500 email messages in it down from ~4500, the memory footprint of the Emacs process goes down from about 620 MB to about 520-550 MB. But this is not with glibc.