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


View this message in rfc822 format

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 40704 <at> debbugs.gnu.org, Eric Abrahamsen <eric <at> ericabrahamsen.net>
Subject: bug#40704: 28.0.50; Improve and speed up (Gnus) registry saving
Date: Sun, 19 Jul 2020 16:52:29 +0200
Lars Ingebrigtsen <larsi <at> gnus.org> writes:


> > +         (princ "#s(hash-table size ")
> > +         (prin1 (hash-table-size thing))
> > +         (princ " test ")
> > +         (prin1 (hash-table-test thing))
> > +         (princ " weakness ")
> > +         (prin1 (hash-table-weakness thing))
> > +         (princ " rehash-size ")
>
> etc
>
> So if the other printer changes, then this has to change, too?  That
> seems kinda brittle -- there should at least be references between the
> two printers with a note to keep them updated if one of them changes.

What do you mean, "other printer"?  The Lisp printer?

This read syntax is officially described in the Elisp manual:

  (info "(elisp) Creating Hash")

(near the end of the page), so I would expect that the syntax will be
supported in the future.

> > diff --git a/lisp/gnus/gnus-registry.el b/lisp/gnus/gnus-registry.el
> > index 480ed80ef8..4ac3c84a80 100644
> > --- a/lisp/gnus/gnus-registry.el
> > +++ b/lisp/gnus/gnus-registry.el
> > @@ -398,6 +398,7 @@ gnus-registry-save
> >    (interactive)
> >    (let* ((file (or file gnus-registry-cache-file))
> >           (db (or db gnus-registry-db))
> > +         (gc-cons-threshold (max gc-cons-threshold (* 800000 500)))
> >  	 (clone (clone db)))
> >      (gnus-message 5 "Saving Gnus registry (%d entries) to %s..."
> >                    (registry-size db) file)
>
> Could this have adverse consequences for people with low memory?

These are 400 MB... Could be?  Dunno.  I wonder, though, if when you
would hit that limit when that code runs, your computer can hold that
huge hash-table at all.  I don't know the relation between hash-table
size and corresponding amount of garbage.  But I guess if you are low on
memory using the registry is problematic per se.

Michael.




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.