[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#40704: 28.0.50; Improve and speed up (Gnus) registry saving
From: |
Eric Abrahamsen |
Subject: |
bug#40704: 28.0.50; Improve and speed up (Gnus) registry saving |
Date: |
Sun, 19 Apr 2020 21:13:45 -0700 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Michael Heerdegen <michael_heerdegen@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