From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.emacs.devel Subject: Re: Larger GC thresholds for non-interactive Emacs Date: Wed, 22 Jun 2022 19:48:59 -0400 Message-ID: References: <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> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000e15c6f05e211fb94" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19643"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen , Eli Zaretskii , Ihor Radchenko , =?UTF-8?Q?Mattias_Engdeg=C3=A5rd?= , Tim Cross , rms@gnu.org, Alan Mackenzie , emacs-devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jun 23 01:50:32 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 1o4A7C-0004sl-2w for ged-emacs-devel@m.gmane-mx.org; Thu, 23 Jun 2022 01:50:30 +0200 Original-Received: from localhost ([::1]:38744 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o4A7A-0001ST-UO for ged-emacs-devel@m.gmane-mx.org; Wed, 22 Jun 2022 19:50:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49822) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o4A5z-0000fE-PS for emacs-devel@gnu.org; Wed, 22 Jun 2022 19:49:15 -0400 Original-Received: from mail-oi1-x233.google.com ([2607:f8b0:4864:20::233]:39607) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o4A5x-0005MH-R7; Wed, 22 Jun 2022 19:49:15 -0400 Original-Received: by mail-oi1-x233.google.com with SMTP id bd16so23221509oib.6; Wed, 22 Jun 2022 16:49:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Bcw+WhKOsugxmlh3TqeUhvHdQ1fVZMwm+i6mNWqlN/w=; b=Gnt5WVBQr9yPYfuXE927tvrcZo4buydO8GaC3CS3DbbUWmxMQfvl4MRofvYrQFOjt0 1f5HugHqzgnBkRL5j1SF+M3p1AtV7jYsyYygJlMhZTzhYvMT/pT3wXLTkph3GKEUiBC+ nrwnGmDN15oTtaYQyOQAr5RvAooGIab3RitFBt6ExnVW71cYkFNb88FGwa98Q9GpDNLA jIkD0hEVu3j9qjdtGgKU96gM8sJS8J8EjNXwg53IKidThPnvT9p961p37da+wonaj/LI 5TqfY0D97WWtDLupnD/C98YFA/E4FxB0s/BcEB6m3uBJvpXEBj/0K2AncUGM2VFEsC+N TUfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Bcw+WhKOsugxmlh3TqeUhvHdQ1fVZMwm+i6mNWqlN/w=; b=HJLb1b2VjXL2TAKo9OKIdJpjWtS6K8AAgwx0f11yFJ3UE/gv+DiCLqDDwBwHpB0wlV 3xINlsFsb75qMHUa4WOByemRkauiE7lvHWHJ7IibFJNSqFFf4XroFxiSyXDWKWzDDVeo SEuoAOliGw5f7SkKsFogOqVvSSfhostoaHf6RoPiGj/BIjfgA0Ps5vpeljZY2X/8nFh5 +AvGF1g2W+6pUh+dqzGAmen+ZtyyaKfRF2+4FP7vx6GQZx5oOB2Anz8F+fO2pltw2gGw DCWiqIM999zGDK3mq9bY8Dgf9XAKr/gmmIllZtVOY0KphLq6ZcpdyHiGH4wXZwDvAO4p H42w== X-Gm-Message-State: AJIora83L/uBUF90dEfJAao0lj3X0igQ2GB4EDJbDk6/azgSorFfX4NW dtVackQV7gMaGkQmwgNtOp3Bdcs51aVquqotwZs= X-Google-Smtp-Source: AGRyM1uSz35nDDBiQEGFz9Z3BJFJtzRf7oRSolkoA4ZGk+cvOdv5YAnXPUesG7U7mueD3cPERZ1oXXXUdrA0nWJxf6E= X-Received: by 2002:a05:6808:1a96:b0:333:289e:713d with SMTP id bm22-20020a0568081a9600b00333289e713dmr551153oib.247.1655941751723; Wed, 22 Jun 2022 16:49:11 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::233; envelope-from=owinebar@gmail.com; helo=mail-oi1-x233.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action 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:291519 Archived-At: --000000000000e15c6f05e211fb94 Content-Type: text/plain; charset="UTF-8" On Wed, Jun 22, 2022 at 7:26 PM Stefan Monnier wrote: > > Was there? I see:. > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38345#71 > > but it's a little more than a couple of months ago. > > I'm pretty curious because if I accumulate a large buffer of trace output > > (running memory up to 100s of MB), killing the buffer doesn't seem to > > impact gc time substantially. > > The GC does not really look at a buffer's content, so unless there is > a non-trivial amount of text-properties (e.g. because of font-lock and > such), the GC will take about the same amount of time handling a large > buffer as handling a tiny buffer. > > Similarly, whether the malloc library returns the memory to the system > or not shouldn't affect GC times very much if at all. What does affect > GC time is the amount of live data as well as the total amount of data > that's under the GC's control (i.e. live data, garbage that still needs > to be collected, as well as data that's free but that we haven't been > able to return to malloc (via `free`)). > > That's why I found it so confusing - as though the gc was traversing malloc's free list. Even if the text were killed and saved in the kill ring, it would be a lisp string, so the GC shouldn't be traversing it. I'm not particularly eager to recreate the problem, as I spent (at least) as much time trying to understand edebug's behavior as the lisp macro I was debugging. It's possible there's something special about the edebug trace buffer, or (I suspect more likely) one of those packages I set up made "kill-buffer" bury them instead. I just remember being very frustrated that the gc time seemed to grow proportional to the size of the trace buffer and not be improved by running garbage-collect after killing that buffer. Lynn --000000000000e15c6f05e211fb94 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jun 22, 2022 at 7:26 PM Stefan Mo= nnier <monnier@iro.umontreal= .ca> wrote:
> Was there?=C2=A0 I see:.=C2=A0 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D383= 45#71
> but it's a little more than a couple of months ago.
> I'm pretty curious because if I accumulate a large buffer of trace= output
> (running memory up to 100s of MB), killing the buffer doesn't seem= to
> impact gc time substantially.

The GC does not really look at a buffer's content, so unless there is a non-trivial amount of text-properties (e.g. because of font-lock and
such), the GC will take about the same amount of time handling a large
buffer as handling a tiny buffer.

Similarly, whether the malloc library returns the memory to the system
or not shouldn't affect GC times very much if at all.=C2=A0 What does a= ffect
GC time is the amount of live data as well as the total amount of data
that's under the GC's control (i.e. live data, garbage that still n= eeds
to be collected, as well as data that's free but that we haven't be= en
able to return to malloc (via `free`)).

That's= why I found it so confusing - as though the gc was traversing malloc's=
free list.=C2=A0 Even if the text were killed and saved in the k= ill ring, it would be a=C2=A0
lisp string, so the GC shouldn'= t be traversing it.=C2=A0

I'm not particularly= eager to recreate the problem, as I spent (at least) as=C2=A0
mu= ch time trying to understand edebug's behavior as the lisp macro I was= =C2=A0
debugging.

It's possible ther= e's something special about the edebug trace buffer, or (I suspect
more likely) one of those packages I set up made "kill-buffer&qu= ot; bury them instead.=C2=A0 I
just remember being very frustrate= d that the gc time seemed to grow proportional to
the size of the= trace buffer and not be improved by running garbage-collect after
killing that buffer.

Lynn
=C2=A0
=
--000000000000e15c6f05e211fb94--