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 #8 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: Sun, 19 Apr 2020 21:13:45 -0700
Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> Hello,
>
> Saving the Gnus registry is quite slow currently.  I profiled a bit and
> for now suggest to do something like in the attached patch.  In detail:
>
> (1) We need to bind inhibit-modification-hooks -> t, this offers a good
> speedup (~ 4 or so).
>
> (2) Printing the registry which basically consists of huge hash tables,
> causes a lot of garbage.  Most of that garbage seems to be unavoidable
> (is it created by the printing primitives?).  Anyway, seems we should
> temporarily increase `gc-cons-threshold' drastically, this offers
> another speedup of 25% or so.  The patch attached uses the value that
> works well for me and the size of my registry, and I bind it in
> `gnus-registry-save', because I assume other registries outside of Gnus
> can be smaller.  What would be a good value of `gc-cons-threshold', or
> should it even scale with `gnus-registry-max-entries' instead of being
> constant?
>
> (3) I also decided to change `eieio-override-prin1' to print hash tables
> "by hand" from Lisp.  The eieio-persistent requires to modify how
> elements in the hash tables are printed, and the current way of doing
> this (make a copy of the complete table, change the elements, prin1 and
> re-read the result) is not only hackish but also inefficient (it does
> this recursively for nested tables).
>
> Any comments on the suggested changes?

Not that it's up to me, 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.

Eric




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

Previous Next


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