bug#46326: 27.1.50; Excessive memory allocations with minibuffer-with-setup-hook

[mail]

Hello Eli!

> If you are saying that the Lisp code in question conses too many
> objects unnecessarily, then the solution is to modify the code to cons
> less objects.  That doesn't necessarily indicates the existence of a
> bug in Emacs, certainly not with its memory management.

My code certainly *does not allocate* too much. It is the add-hook 
implementation
or more precisely the minibuffer-with-setup-hook implementation which is
responsible for the excessive allocations. For this reason this is an 
upstream
bug. In my workaround, I am replacing the upstream version of 
minibuffer-with-setup-hook
with my own version to show the difference. This does not mean that I 
consider
the problem to be gone. I rather decided to report the problem instead.

> So if you already have a solution for the problem, what is it that you
> want us as Emacs maintainers to investigate and fix here?

I am actually not sure what the proper upstream fix is. I see the 
following
options.

1. Replace minibuffer-with-setup-hook with my version if you think
   my version is better and an acceptable fix.
2. Investigate the reasons why add-hook with priorities somehow copies
   large closures during sorting. This is unacceptably costly.

To give you a better picture of the overall situation - it looks like 
this:

    (minibuffer-with-setup-hook
        (lambda () ...large closure...)
      (minibuffer-with-setup-hook
          (lambda () ...another large closure...)
        (minibuffer-with-setup-hook
            (:append (lambda () ...and yet another one...))
          (completing-read ...))))

The bug is that the large closures are copied for some unknown reason in 
the
add-hook calls which I am not controlling as a library author. My 
replacement
adds the hooks in another way, by creating a symbol+fset instead of 
putting the
lambda directly in the minibuffer-setup-hook variable.

Daniel