GNU bug report logs - #40704
28.0.50; Improve and speed up (Gnus) registry saving

Previous Next

Package: emacs;

Reported by: Michael Heerdegen <michael_heerdegen <at> web.de>

Date: Sun, 19 Apr 2020 02:15:01 UTC

Severity: normal

Tags: patch

Found in version 28.0.50

Full log


Message #14 received at 40704 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 40704 <at> debbugs.gnu.org
Subject: Re: bug#40704: 28.0.50; Improve and speed up (Gnus) registry saving
Date: Mon, 20 Apr 2020 20:42:21 -0700
Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>> > Any comments on the suggested changes?
>>
>> Not that it's up to me,
>
> I wonder who it's up to...

There's sort of a `with-gnus-bug-report' macro that we're working with
here, where if Lars (or in this case, Ted Zlatanov) doesn't respond
within a certain period of time, the commit automatically goes in.

>> but I'm all for putting in #1 and #3 as-is, and adjusting #2 to scale
>> with the number of `gnus-registry-max-entries', with the addition of a
>> hard ceiling.
>
> Too large values of `gnus-registry-max-entries' can be harmful
> (fragmentation of memory?), I wonder if this can potentially be the case
> here.

Well that's where the hard ceiling comes in, right?

> I'm also not sure if scaling is a good idea at all.  The value I chose
> will still make gc happen much less frequently even if your registry is
> huge.  So it's still a win.  If your value is too large, the final
> cleanup may take longer as necessary -- who has experience with this
> problem -- anybody?

Not me, let's hope for more respondents...




This bug report was last modified 3 years and 120 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.