[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#46326: 27.1.50; Excessive memory allocations with minibuffer-with-se
From: |
mail |
Subject: |
bug#46326: 27.1.50; Excessive memory allocations with minibuffer-with-setup-hook |
Date: |
Fri, 05 Feb 2021 16:20:13 +0100 |
User-agent: |
Roundcube Webmail/1.2-git |
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
consult-2a197310923a732033bdb757b20c6f90cfad784a.el
Description: Text document
consult-27e055e7c75e2148449e7b0be4d464b03c36a1bd.el
Description: Text document