bug#40704: 28.0.50; Improve and speed up (Gnus) registry saving

[Lars Ingebrigtsen <larsi@gnus.org>]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> (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).

Yeah, the current implementation seems maximally inefficient...  But I
guess this copies functionality found elsewhere?

> +         (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.

> 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?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no