* Long delay after M-x commandname
@ 2021-10-11 0:45 Eduardo Ochs
2021-10-11 4:03 ` Stefan Monnier via Users list for the GNU Emacs text editor
2021-10-12 0:19 ` Michael Heerdegen
0 siblings, 2 replies; 8+ messages in thread
From: Eduardo Ochs @ 2021-10-11 0:45 UTC (permalink / raw)
To: help-gnu-emacs
Hi list,
this is not a bug report YET - I am looking for more information
first.
Yesterday I noticed that when I was invoking commands with M-x
commandname and using tab for completing parts of the name then
sometimes there would be a long delay - sometimes as long as 10
seconds, but my laptop is quite old - between the RET and the
execution of the command. This delay was big on emacs28 and
practically imperceptible on emacs27. I have several versions of
emacs28 here, with names like emacs28_512 for the one correponding to
HEAD~512 and emacs28_0 for HEAD, and I noticed that this delay was
growing in recent versions: small in HEAD~256, bigger in HEAD~128,
much bigger in HEAD~0.
I _guess_ that these delays are caused by the code that generates
messages like this one:
You can run the command `find-eev-install-intro' with `M-x f--i-i'.
What do I need to learn to understand what is going on, and to prepare
a proper bug report? A quick grepping shows that this message is
generated by `execute-extended-command' in simple.el, but what else?
Thanks in advance,
Eduardo Ochs
http://angg.twu.net/#eev
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Long delay after M-x commandname
2021-10-11 0:45 Long delay after M-x commandname Eduardo Ochs
@ 2021-10-11 4:03 ` Stefan Monnier via Users list for the GNU Emacs text editor
2021-10-11 12:07 ` Eli Zaretskii
2021-10-12 10:07 ` Michael Heerdegen
2021-10-12 0:19 ` Michael Heerdegen
1 sibling, 2 replies; 8+ messages in thread
From: Stefan Monnier via Users list for the GNU Emacs text editor @ 2021-10-11 4:03 UTC (permalink / raw)
To: help-gnu-emacs
Eduardo Ochs [2021-10-10 21:45:39] wrote:
> Hi list,
>
> this is not a bug report YET - I am looking for more information
> first.
>
> Yesterday I noticed that when I was invoking commands with M-x
> commandname and using tab for completing parts of the name then
> sometimes there would be a long delay - sometimes as long as 10
> seconds, but my laptop is quite old - between the RET and the
> execution of the command. This delay was big on emacs28 and
> practically imperceptible on emacs27. I have several versions of
> emacs28 here, with names like emacs28_512 for the one correponding to
> HEAD~512 and emacs28_0 for HEAD, and I noticed that this delay was
> growing in recent versions: small in HEAD~256, bigger in HEAD~128,
> much bigger in HEAD~0.
>
> I _guess_ that these delays are caused by the code that generates
> messages like this one:
>
> You can run the command `find-eev-install-intro' with `M-x f--i-i'.
This message can be suppressed with `extended-command-suggest-shorter`.
It can take work to find that shortest replacement (it's a kind of
brute-force algorithm which tries all combinations of increasing length
until one works), indeed, tho usually it's negligible. I'm surprised
the time taken has changed significantly recently That code has been
the same Emacs-26, AFAIK. The completion data has an impact on the
performance, so maybe that's what's going on, but it still seems
surprising you'd see such a progressive slowdown.
Stefan
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Long delay after M-x commandname
2021-10-11 4:03 ` Stefan Monnier via Users list for the GNU Emacs text editor
@ 2021-10-11 12:07 ` Eli Zaretskii
2021-10-12 10:07 ` Michael Heerdegen
1 sibling, 0 replies; 8+ messages in thread
From: Eli Zaretskii @ 2021-10-11 12:07 UTC (permalink / raw)
To: help-gnu-emacs
> Date: Mon, 11 Oct 2021 00:03:19 -0400
> From: Stefan Monnier via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
>
> Eduardo Ochs [2021-10-10 21:45:39] wrote:
>
> > Yesterday I noticed that when I was invoking commands with M-x
> > commandname and using tab for completing parts of the name then
> > sometimes there would be a long delay - sometimes as long as 10
> > seconds, but my laptop is quite old - between the RET and the
> > execution of the command. This delay was big on emacs28 and
> > practically imperceptible on emacs27. I have several versions of
> > emacs28 here, with names like emacs28_512 for the one correponding to
> > HEAD~512 and emacs28_0 for HEAD, and I noticed that this delay was
> > growing in recent versions: small in HEAD~256, bigger in HEAD~128,
> > much bigger in HEAD~0.
> >
> > I _guess_ that these delays are caused by the code that generates
> > messages like this one:
> >
> > You can run the command `find-eev-install-intro' with `M-x f--i-i'.
>
> This message can be suppressed with `extended-command-suggest-shorter`.
>
> It can take work to find that shortest replacement (it's a kind of
> brute-force algorithm which tries all combinations of increasing length
> until one works), indeed, tho usually it's negligible. I'm surprised
> the time taken has changed significantly recently That code has been
> the same Emacs-26, AFAIK. The completion data has an impact on the
> performance, so maybe that's what's going on, but it still seems
> surprising you'd see such a progressive slowdown.
FWIW, I don't see any delay in "emacs -Q", so I think the question
becomes what kind of customizations and packages loaded could
significantly increase that time.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Long delay after M-x commandname
2021-10-11 4:03 ` Stefan Monnier via Users list for the GNU Emacs text editor
2021-10-11 12:07 ` Eli Zaretskii
@ 2021-10-12 10:07 ` Michael Heerdegen
1 sibling, 0 replies; 8+ messages in thread
From: Michael Heerdegen @ 2021-10-12 10:07 UTC (permalink / raw)
To: Stefan Monnier via Users list for the GNU Emacs text editor
Cc: Stefan Monnier
Stefan Monnier via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:
> It can take work to find that shortest replacement (it's a kind of
> brute-force algorithm which tries all combinations of increasing length
> until one works) [...]
I would expect that working with decreasing lengths and stop when there
are no more solutions would be more efficient (since starting with tiny
lengths has nearly no chance of success, especially when having a lot of
interned symbols, and the smaller lengths also seem to have the higher
costs.)
Apart from that, I get a significant improvement if I move the commandp
test out of the `try-completion' call and filter the obarray once for a
list of commands.
I will try to suggest a patch for the bug report. For the
`find-eev-install-intro' test case I get 0.6 instead of 2.5 seconds
here.
Michael.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Long delay after M-x commandname
2021-10-11 0:45 Long delay after M-x commandname Eduardo Ochs
2021-10-11 4:03 ` Stefan Monnier via Users list for the GNU Emacs text editor
@ 2021-10-12 0:19 ` Michael Heerdegen
2021-10-12 1:05 ` Eduardo Ochs
1 sibling, 1 reply; 8+ messages in thread
From: Michael Heerdegen @ 2021-10-12 0:19 UTC (permalink / raw)
To: help-gnu-emacs
Eduardo Ochs <eduardoochs@gmail.com> writes:
> I _guess_ that these delays are caused by the code that generates
> messages like this one:
Adding to what already has been mentioned: There is a `sit-for' of (by
default) 2 seconds for displaying the found shorter version of the input.
But that doesn't explain 10 seconds.
If you can reproduce your problem, my first debugging approach would be
to enable `debug-on-quit' and hit C-g when there is a delay, and look
what Emacs was actually doing at that moment.
Michael.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Long delay after M-x commandname
2021-10-12 0:19 ` Michael Heerdegen
@ 2021-10-12 1:05 ` Eduardo Ochs
2021-10-12 1:59 ` Michael Heerdegen
0 siblings, 1 reply; 8+ messages in thread
From: Eduardo Ochs @ 2021-10-12 1:05 UTC (permalink / raw)
To: Michael Heerdegen; +Cc: help-gnu-emacs
On Mon, 11 Oct 2021 at 21:20, Michael Heerdegen
<michael_heerdegen@web.de> wrote:
>
> Eduardo Ochs <eduardoochs@gmail.com> writes:
>
> > I _guess_ that these delays are caused by the code that generates
> > messages like this one:
>
> Adding to what already has been mentioned: There is a `sit-for' of (by
> default) 2 seconds for displaying the found shorter version of the input.
> But that doesn't explain 10 seconds.
>
> If you can reproduce your problem, my first debugging approach would be
> to enable `debug-on-quit' and hit C-g when there is a delay, and look
> what Emacs was actually doing at that moment.
>
> Michael.
Hi Michael,
I can reproduce it without M-x.
This takes 10 seconds:
(execute-extended-command--shorter "find-eev-quick-intro" "find-eev-qui")
This executes very quickly:
(execute-extended-command--shorter-1 "find-eev-quick-intro" 12)
If I run `(setq debug-on-quit t)' and I hit a C-g during the execution
of the sexp that takes a long time I get a "*Backtrace*" buffer whose
top lines are these ones,
Debugger entered--Lisp error: (quit)
all-completions("" [find-udfile magit-section-show-headings
org-element-paragraph-separate calendar-forward-week
archive-proper-file-start
tramp-completion-handle-file-name-all-completions
archive--file-desc-mode lua-backward-up-list
speedbar-check-vc-this-line access-label find-operatorspacepage
c-electric-lt-gt pcomplete-stub c-state-min-scan-pos
gnus-article-nndoc-name vterm-keymap-exceptions
magit-buffer-lock-functions magit-xref-insert-button
speedbar-file-regexp gnus-agent-group-covered-p
org-table--descriptor-line raw-text-dos message-expand-name-databases
transient:magit-diff-refresh:--irreversible-delete
find-oofficestylestext c-make-ml-string-opener-re-function
smie-config--guess-value compilation-error-list
find-sexptotarget-links lua-is-continuing-statement-p-1
c-list-found-types vc-annotate tramp-sudoedit-handle-set-file-acl
org-table-get-range vc-bzr-shelve-menu gamr
widget-face-sample-face-get nnimap-status-message int-file-name
he-line-search-regexp nnmail-message-id-cache-file discard-new
filename-and-process smime-buffer-as-string-region keyid check-declare
org-at-keyword-p angle-bracket-arglist-escape bibtex-text-in-string
zot ...] commandp)
completion-pcm--all-completions("" (any "-" any-delim "ee")
[find-udfile magit-section-show-headings
org-element-paragraph-separate calendar-forward-week
archive-proper-file-start
tramp-completion-handle-file-name-all-completions
archive--file-desc-mode lua-backward-up-list
speedbar-check-vc-this-line access-label find-operatorspacepage
c-electric-lt-gt pcomplete-stub c-state-min-scan-pos
gnus-article-nndoc-name vterm-keymap-exceptions
magit-buffer-lock-functions magit-xref-insert-button
speedbar-file-regexp gnus-agent-group-covered-p
org-table--descriptor-line raw-text-dos message-expand-name-databases
transient:magit-diff-refresh:--irreversible-delete
find-oofficestylestext c-make-ml-string-opener-re-function
smie-config--guess-value compilation-error-list
find-sexptotarget-links lua-is-continuing-statement-p-1
c-list-found-types vc-annotate tramp-sudoedit-handle-set-file-acl
org-table-get-range vc-bzr-shelve-menu gamr
widget-face-sample-face-get nnimap-status-message int-file-name
he-line-search-regexp nnmail-message-id-cache-file discard-new
filename-and-process smime-buffer-as-string-region keyid check-declare
org-at-keyword-p angle-bracket-arglist-escape bibtex-text-in-string
zot ...] commandp)
completion-pcm--find-all-completions("-ee" [find-udfile
magit-section-show-headings org-element-paragraph-separate
calendar-forward-week archive-proper-file-start
tramp-completion-handle-file-name-all-completions
archive--file-desc-mode lua-backward-up-list
speedbar-check-vc-this-line access-label find-operatorspacepage
c-electric-lt-gt pcomplete-stub c-state-min-scan-pos
gnus-article-nndoc-name vterm-keymap-exceptions
magit-buffer-lock-functions magit-xref-insert-button
speedbar-file-regexp gnus-agent-group-covered-p
org-table--descriptor-line raw-text-dos message-expand-name-databases
transient:magit-diff-refresh:--irreversible-delete
find-oofficestylestext c-make-ml-string-opener-re-function
smie-config--guess-value compilation-error-list
find-sexptotarget-links lua-is-continuing-statement-p-1
c-list-found-types vc-annotate tramp-sudoedit-handle-set-file-acl
org-table-get-range vc-bzr-shelve-menu gamr
widget-face-sample-face-get nnimap-status-message int-file-name
he-line-search-regexp nnmail-message-id-cache-file discard-new
filename-and-process smime-buffer-as-string-region keyid check-declare
org-at-keyword-p angle-bracket-arglist-escape bibtex-text-in-string
zot ...] commandp 3 nil)
completion-pcm-try-completion("-ee" [find-udfile
magit-section-show-headings org-element-paragraph-separate
calendar-forward-week archive-proper-file-start
tramp-completion-handle-file-name-all-completions
archive--file-desc-mode lua-backward-up-list
speedbar-check-vc-this-line access-label find-operatorspacepage
c-electric-lt-gt pcomplete-stub c-state-min-scan-pos
gnus-article-nndoc-name vterm-keymap-exceptions
magit-buffer-lock-functions magit-xref-insert-button
speedbar-file-regexp gnus-agent-group-covered-p
org-table--descriptor-line raw-text-dos message-expand-name-databases
transient:magit-diff-refresh:--irreversible-delete
find-oofficestylestext c-make-ml-string-opener-re-function
smie-config--guess-value compilation-error-list
find-sexptotarget-links lua-is-continuing-statement-p-1
c-list-found-types vc-annotate tramp-sudoedit-handle-set-file-acl
org-table-get-range vc-bzr-shelve-menu gamr
widget-face-sample-face-get nnimap-status-message int-file-name
he-line-search-regexp nnmail-message-id-cache-file discard-new
filename-and-process smime-buffer-as-string-region keyid check-declare
org-at-keyword-p angle-bracket-arglist-escape bibtex-text-in-string
zot ...] commandp 3)
#f(compiled-function (style) #<bytecode
-0xd2f42ee755385a2>)(partial-completion)
completion--some(#f(compiled-function (style) #<bytecode
-0xd2f42ee755385a2>) (basic partial-completion emacs22))
completion--nth-completion(1 "-ee" [find-udfile
magit-section-show-headings org-element-paragraph-separate
calendar-forward-week archive-proper-file-start
tramp-completion-handle-file-name-all-completions
archive--file-desc-mode lua-backward-up-list
speedbar-check-vc-this-line access-label find-operatorspacepage
c-electric-lt-gt pcomplete-stub c-state-min-scan-pos
gnus-article-nndoc-name vterm-keymap-exceptions
magit-buffer-lock-functions magit-xref-insert-button
speedbar-file-regexp gnus-agent-group-covered-p
org-table--descriptor-line raw-text-dos message-expand-name-databases
transient:magit-diff-refresh:--irreversible-delete
find-oofficestylestext c-make-ml-string-opener-re-function
smie-config--guess-value compilation-error-list
find-sexptotarget-links lua-is-continuing-statement-p-1
c-list-found-types vc-annotate tramp-sudoedit-handle-set-file-acl
org-table-get-range vc-bzr-shelve-menu gamr
widget-face-sample-face-get nnimap-status-message int-file-name
he-line-search-regexp nnmail-message-id-cache-file discard-new
filename-and-process smime-buffer-as-string-region keyid check-declare
org-at-keyword-p angle-bracket-arglist-escape bibtex-text-in-string
zot ...] commandp 3 nil)
completion-try-completion("-ee" [find-udfile
magit-section-show-headings org-element-paragraph-separate
calendar-forward-week archive-proper-file-start
tramp-completion-handle-file-name-all-completions
archive--file-desc-mode lua-backward-up-list
speedbar-check-vc-this-line access-label find-operatorspacepage
c-electric-lt-gt pcomplete-stub c-state-min-scan-pos
gnus-article-nndoc-name vterm-keymap-exceptions
magit-buffer-lock-functions magit-xref-insert-button
speedbar-file-regexp gnus-agent-group-covered-p
org-table--descriptor-line raw-text-dos message-expand-name-databases
transient:magit-diff-refresh:--irreversible-delete
find-oofficestylestext c-make-ml-string-opener-re-function
smie-config--guess-value compilation-error-list
find-sexptotarget-links lua-is-continuing-statement-p-1
c-list-found-types vc-annotate tramp-sudoedit-handle-set-file-acl
org-table-get-range vc-bzr-shelve-menu gamr
widget-face-sample-face-get nnimap-status-message int-file-name
he-line-search-regexp nnmail-message-id-cache-file discard-new
filename-and-process smime-buffer-as-string-region keyid check-declare
org-at-keyword-p angle-bracket-arglist-escape bibtex-text-in-string
zot ...] commandp 3)
execute-extended-command--shorter("find-eev-quick-intro" "find-eev-qui")
I repeated that 10 times and in all the times the "*Backtrace*" buffer
had something like this:
#f(compiled-function (style) #<bytecode
-0xd2f4350b61385a2>)(partial-completion)
completion--some(...)
completion--nth-completion(...)
completion-try-completion(...)
Cheers,
Eduardo Ochs
http://angg.twu.net/#eev
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Long delay after M-x commandname
2021-10-12 1:05 ` Eduardo Ochs
@ 2021-10-12 1:59 ` Michael Heerdegen
2021-10-12 9:52 ` Michael Heerdegen
0 siblings, 1 reply; 8+ messages in thread
From: Michael Heerdegen @ 2021-10-12 1:59 UTC (permalink / raw)
To: help-gnu-emacs
Eduardo Ochs <eduardoochs@gmail.com> writes:
> This takes 10 seconds:
>
> (execute-extended-command--shorter "find-eev-quick-intro"
> "find-eev-qui")
Wow - takes 36 seconds for me. In emacs -Q still 2 or 3 seconds. I
think a bug report would definitely not be wrong.
Here is the result of running the profiler (using my current session).
I don't see anything obvious - no sit-for or so. Maybe it depends on
completion-styles involved? Let's try ... eh, no, with the default
styles enabled I still see 34 seconds. Maybe this just scales with the
amount of loaded packages and "find-eev-quick-intro" is just very hard
to shorten, dunno. Anyway, here is the profiler result:
Elapsed time: 35.878s (including 1.239s in 1 GCs and excluding 0.479s of idle time)
Conses: 511713
Vector-Cells: 42
Strings: 32135
String-Chars: 100
Symbols: 1.10411e+06
Floats: 606
Intervals: 138814
34239 100% - ...
33925 99% - read-from-minibuffer
33925 99% - command-execute
33925 99% - call-interactively
33925 99% - funcall-interactively
33886 98% - my-profiler-profile-next-command
33886 98% - my-measuring-idle-time
33886 98% - #<compiled 0x2ec4e28c32523d9>
33886 98% - eval
33886 98% - benchmark-run
33886 98% - benchmark-call
33886 98% - #<lambda 0xfdda4d053>
33886 98% - progn
33886 98% - funcall-interactively
33886 98% - my-pp-eval-expression
33800 98% - pp-eval-expression
33800 98% - eval
33800 98% - progn
33800 98% - progn
33800 98% - execute-extended-command--shorter
33760 98% - completion-try-completion
33760 98% - completion--nth-completion
33756 98% - completion--some
33756 98% - #<compiled -0xd2c16e5a3854222>
19670 57% - completion-pcm-try-completion
19566 57% - completion-pcm--find-all-completions
19562 57% - completion-pcm--all-completions
4 0% completion-pcm--pattern->regex
104 0% - completion-pcm--merge-try
72 0% completion-pcm--merge-completions
10354 30% - completion-substring-try-completion
10354 30% - completion-substring--all-completions
10350 30% completion-pcm--all-completions
3732 10% completion-emacs22-try-completion
4 0% completion--styles
8 0% - execute-extended-command--shorter-1
[...]
Michael
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Long delay after M-x commandname
2021-10-12 1:59 ` Michael Heerdegen
@ 2021-10-12 9:52 ` Michael Heerdegen
0 siblings, 0 replies; 8+ messages in thread
From: Michael Heerdegen @ 2021-10-12 9:52 UTC (permalink / raw)
To: help-gnu-emacs
Michael Heerdegen <michael_heerdegen@web.de> writes:
> > (execute-extended-command--shorter "find-eev-quick-intro"
> > "find-eev-qui")
>
> Wow - takes 36 seconds for me. In emacs -Q still 2 or 3 seconds.
FWIW, the 36 seconds happened when trying without having a command named
`find-eev-quick-intro' defined, so that was not really a fair test.
Michael.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-10-12 10:07 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-10-11 0:45 Long delay after M-x commandname Eduardo Ochs
2021-10-11 4:03 ` Stefan Monnier via Users list for the GNU Emacs text editor
2021-10-11 12:07 ` Eli Zaretskii
2021-10-12 10:07 ` Michael Heerdegen
2021-10-12 0:19 ` Michael Heerdegen
2021-10-12 1:05 ` Eduardo Ochs
2021-10-12 1:59 ` Michael Heerdegen
2021-10-12 9:52 ` Michael Heerdegen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).