Hello Eli,

thank you for your prompt answer!

> Please show information about the memory consumption.  (The so-called
> "memory profile" doesn't actually measure memory consumption at all,
> it just uses memory allocation calls as a poor-man's profiling
> signal.)

Yes, I am aware. I am not saying that live memory is the problem, but 
the
excessive amount of allocations is a problem, which creates unnecessary 
garbage
collector pauses. Therefore I can also not show you a profile of the 
memory
consumption, since it is not relevant.

> Please show a recipe starting from "emacs -Q" where a lot of memory is
> being consumed, and please show how much memory does the recipe
> consume.  Also, I presume invoking "M-x garbage-collect RET" doesn't
> release that memory?  If so, please show the return value of
> garbage-collect.

I hope it is not asking too much to load a single elisp file 
(consult.el)? The
package file has no further dependencies besides Emacs. Then I can give 
you the
following reproducible. The only difference between the two files is 
that in one
case minibuffer-with-setup-hook is used and in the other case
consult--minibuffer-with-setup-hook is used. I appended the two files. 
The hashes
correspond to the git commit hashes in case you want to pull the files 
from the
git repository.

     ;; excessive allocations - using minibuffer-with-setup-hook
     (load "consult-2a197310923a732033bdb757b20c6f90cfad784a.el")

     ;; no suspicious allocations - using 
consult--minibuffer-with-setup-hook
     ;;(load "consult-27e055e7c75e2148449e7b0be4d464b03c36a1bd.el")

     (profiler-start 'mem)
     (dotimes (count 100)
       (run-at-time 0 nil (lambda ()
         		     (message "%s" count)
         		     (setq unread-command-events '(?\C-g))))
       (condition-case _
           (consult-buffer)
         (quit)))
     (profiler-stop)
     (profiler-report)

>> See the issue https://github.com/minad/consult/issues/193 for 
>> reference.
> 
> I don't see any memory information in that discussion.  I guess you
> thought the memory profiler somehow shows memory consumption, but it
> doesn't.

The profile in the issue shows the memory allocation profile. I think 
you refer
to my comment
https://github.com/minad/consult/issues/193#issuecomment-770416491, 
where I
stated my confusion, since the creator of the issue talked about "memory 
usage".
I was only wondering what the profiler actually measures and I looked 
into the
profiler code to confirm that it indeed measures allocations.

> What exactly caused you to run the profiler? is the code slow or
> something?  If so, the problem may be something other than memory
> consumption.

Yes, it is slow. Add-hook performs unnecessary allocations causing 
pauses. After
replacing the minibuffer-with-setup-hook default implementation with my
workaround the memory allocations went away and the command is much 
faster. The
add-hook calls do not appear in the memory profile anymore. See the 
comment
https://github.com/minad/consult/issues/193#issuecomment-770650405.

      56,846,572  89%       - consult-buffer
      56,846,572  89%        - consult--buffer
      56,846,572  89%         - consult--multi
      53,076,020  83%          - consult--read
      53,076,020  83%           - apply
      53,076,020  83%            - #<compiled -0x1bf0d3486ff553f9>
      53,076,020  83%             - consult--with-async-1
      53,076,020  83%              - #<compiled 0x3e0275e58912bf7>
      53,076,020  83%               - consult--with-preview-1
      53,074,964  83%                - #<compiled -0xbfb98ce1324d29c>
      53,074,964  83%                 - completing-read
      53,074,964  83%                  - selectrum-completing-read
       5,530,436   8%                   + selectrum-read
          70,240   0%          + consult--multi-candidates
           4,360   0%            consult--multi-predicate
           1,056   0%          + consult--multi-preprocess

Daniel Mendler