[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: |
Michael Heerdegen |
Subject: |
bug#40704: 28.0.50; Improve and speed up (Gnus) registry saving |
Date: |
Sun, 19 Apr 2020 04:14:00 +0200 |
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?
TIA,
Michael.
0001-WIP-Try-to-improve-gnus-registry-saving.patch
Description: Text Data
- bug#40704: 28.0.50; Improve and speed up (Gnus) registry saving,
Michael Heerdegen <=