Package: emacs;
Reported by: Nicolas Sarlin <nico.sarlin <at> gmail.com>
Date: Wed, 29 Jan 2025 11:16:02 UTC
Severity: normal
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 75922 in the body.
You can then email your comments to 75922 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
bug-gnu-emacs <at> gnu.org:bug#75922; Package emacs.
(Wed, 29 Jan 2025 11:16:02 GMT) Full text and rfc822 format available.Nicolas Sarlin <nico.sarlin <at> gmail.com>:bug-gnu-emacs <at> gnu.org.
(Wed, 29 Jan 2025 11:16:02 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Nicolas Sarlin <nico.sarlin <at> gmail.com> To: bug-gnu-emacs <at> gnu.org Subject: CPU hogs with pgtk Date: Wed, 29 Jan 2025 12:05:16 +0100
[Message part 1 (text/plain, inline)]
Hello,
I'm using lsp-mode with corfu on the emacs-30 branch, and I get extremely
frequent CPU hogs (CPU runs at 100% for a few seconds) while typing
code. I report this as an emacs bug because it seems to only occurs when
emacs is compiled with pgtk. If I rebuild emacs with "make bootstrap
configure=default" the bug disapears.
Here is a profiler record:
11152 91% - corfu--post-command
11152 91% - corfu--exhibit
11043 90% - corfu--update
10891 88% - corfu--recompute
10891 88% - corfu--filter-completions
10891 88% - completion-all-completions
10891 88% - completion--nth-completion
10891 88% - seq-some
10891 88% - seq-do
10891 88% - mapc
10891 88% - #<byte-code-function AC1>
10891 88% - #<byte-code-function AD0>
10891 88% - lsp-completion-passthrough-all-completions
10891 88% - #<byte-code-function 4B5>
10891 88% - #<byte-code-function 4DE>
10888 88% - lsp-request-while-no-input
10888 88% - sit-for
82 0% + redisplay_internal (C function)
18 0% + #<byte-code-function 31C>
3 0% + lsp--text-document-position-params
152 1% + redisplay
89 0% + posn-at-point
20 0% + corfu--candidates-popup
674 5% + command-execute
269 2% + redisplay_internal (C function)
74 0% + #<byte-code-function 31C>
59 0% + timer-event-handler
25 0% + ...
Please tell me if you need more information,
Thank you for your help
In GNU Emacs 30.0.93 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.43, cairo version 1.18.2) of 2025-01-27 built on zama-laptop
Repository revision: 84595cbcc78b1ea44302f22b83a7d722940c6e49
Repository branch: emacs-30
System Description: Arch Linux
Configured using:
'configure --with-pgtk'
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LCMS2 LIBOTF LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY
PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM GTK3 ZLIB
Important settings:
value of $LC_MONETARY: fr_FR.UTF-8
value of $LC_NUMERIC: fr_FR.UTF-8
value of $LC_TIME: fr_FR.UTF-8
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: Message
Minor modes in effect:
editorconfig-mode: t
global-corfu-mode: t
corfu-mode: t
mml-mode: t
tooltip-mode: t
global-eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
minibuffer-regexp-mode: t
column-number-mode: t
line-number-mode: t
auto-fill-function: message-do-auto-fill
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
abbrev-mode: t
hs-minor-mode: t
Load-path shadows:
None found.
Features:
(mailalias mailclient textsec uni-scripts idna-mapping ucs-normalize
uni-confusable textsec-check ispell help-fns profiler flymake
lsp-diagnostics lsp-headerline lsp-modeline lsp-lens view lsp-zig
lsp-yang lsp-yaml lsp-xml lsp-wgsl lsp-volar lsp-vimscript lsp-vhdl
lsp-vetur lsp-verilog lsp-vala lsp-v lsp-typespec lsp-typeprof lsp-ttcn3
lsp-ts-query lsp-trunk lsp-toml lsp-tilt lsp-tex lsp-terraform
lsp-svelte lsp-steep lsp-sqls lsp-sql lsp-sorbet lsp-solidity
lsp-solargraph lsp-semgrep lsp-rust lsp-ruff lsp-ruby-syntax-tree
lsp-ruby-lsp lsp-rubocop lsp-roslyn lsp-roc lsp-rf lsp-remark lsp-racket
lsp-r lsp-qml lsp-pylsp lsp-pyls lsp-pwsh lsp-purescript lsp-pls lsp-php
lsp-perlnavigator lsp-perl lsp-openscad lsp-ocaml lsp-nushell lsp-nix
lsp-nim lsp-nginx lsp-nextflow lsp-move lsp-mojo lsp-mint lsp-meson
lsp-mdx lsp-matlab lsp-marksman lsp-markdown lsp-magik lsp-fennel
lsp-lua lsp-lisp lsp-kubernetes-helm lsp-kotlin lsp-json lsp-jq
lsp-idris lsp-haxe lsp-hack lsp-groovy lsp-graphql lsp-golangci-lint
lsp-glsl lsp-gleam lsp-gdscript lsp-fsharp lsp-futhark lsp-fortran
lsp-eslint lsp-erlang lsp-emmet lsp-elm lsp-elixir lsp-earthly
lsp-dockerfile lsp-dhall lsp-d lsp-cypher lsp-cucumber lsp-copilot
lsp-css lsp-csharp lsp-crystal lsp-credo lsp-cobol lsp-cmake lsp-clojure
lsp-clangd lsp-bufls lsp-beancount lsp-bash lsp-awk lsp-autotools
lsp-astro lsp-asm lsp-ansible lsp-angular lsp-ada lsp-actionscript
vc-git diff-mode track-changes vc-dispatcher misearch multi-isearch
shadow sort mail-extr emacsbug editorconfig editorconfig-core
editorconfig-core-handle editorconfig-fnmatch rust-utils rust-prog-mode
rust-mode rust-playpen rust-cargo rust-common rust-rustfmt rust-compile
rust-mode-autoloads corfu compat corfu-autoloads lsp-ui lsp-ui-doc
lsp-ui-imenu lsp-ui-peek lsp-ui-sideline find-func goto-addr lsp-ui-util
face-remap lsp-ui-autoloads lsp-javascript lsp-html ido lsp-icons dom
lsp-go lsp-completion lsp-semantic-tokens lsp-mode comp comp-cstr
lsp-protocol xref tree-widget spinner markdown-mode lv imenu ht
filenotify f ewoc lsp-mode-autoloads s f-autoloads s-autoloads inline
dash ht-autoloads info dash-autoloads spinner-autoloads pcase color
thingatpt noutline outline markdown-mode-autoloads easy-mmode warnings
lv-autoloads loaddefs-gen lisp-mnt radix-tree tar-mode arc-mode
archive-mode cus-edit pp cus-start cus-load wid-edit mm-archive message
sendmail yank-media dired dired-loaddefs rfc822 mml mml-sec epa derived
gnus-util time-date mailabbrev gmm-utils mailheader mm-decode mm-bodies
mm-encode mail-utils gnutls network-stream url-cache url-http url-auth
mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr url-gw
nsm puny compile text-property-search comint ansi-osc ansi-color ring
comp-run comp-common rx epg rfc6068 epg-config use-package-ensure
project finder-inf package browse-url url url-proxy url-privacy
url-expand url-methods url-history url-cookie generate-lisp-file
url-domsuf url-util mailcap url-handlers url-parse auth-source eieio
eieio-core icons password-cache json subr-x map byte-opt url-vars
cl-macs gv cl-extra help-mode cl-seq use-package-core cl-loaddefs cl-lib
bytecomp byte-compile rmc iso-transl tooltip cconv eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/pgtk-win pgtk-win term/common-win touch-screen pgtk-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo gtk pgtk
lcms2 multi-tty move-toolbar make-network-process native-compile emacs)
Memory information:
((conses 16 1165555 834435) (symbols 48 39223 34) (strings 32 289158 102434)
(string-bytes 1 6818416) (vectors 16 137350) (vector-slots 8 1772485
595550)
(floats 8 631 1411) (intervals 56 5673 2695) (buffers 992 36))
[Message part 2 (text/html, inline)]
bug-gnu-emacs <at> gnu.org:bug#75922; Package emacs.
(Wed, 29 Jan 2025 12:42:02 GMT) Full text and rfc822 format available.Message #8 received at 75922 <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Nicolas Sarlin <nico.sarlin <at> gmail.com> Cc: 75922 <at> debbugs.gnu.org Subject: Re: bug#75922: CPU hogs with pgtk Date: Wed, 29 Jan 2025 12:41:14 +0000
"Nicolas Sarlin" <nico.sarlin <at> gmail.com> writes: Thanks for the report! Debug suggestions below, but if you cannot or would prefer not to any or all of that, that's perfectly okay, too! > I'm using lsp-mode with corfu on the emacs-30 branch, and I get extremely > frequent CPU hogs (CPU runs at 100% for a few seconds) while typing > code. So this happens on the pgtk branch, but behavior on the master branch is not noticeably slower than you'd expect? > I report this as an emacs bug because it seems to only occurs when > emacs is compiled with pgtk. Are you running this on a Wayland setup, or on X (ignoring the popup)? > If I rebuild emacs with "make bootstrap configure=default" the bug > disapears. Entirely? > Here is a profiler record: > 11152 91% - corfu--post-command > 11152 91% - corfu--exhibit > 11043 90% - corfu--update > 10891 88% - corfu--recompute > 10891 88% - corfu--filter-completions > 10891 88% - completion-all-completions > 10891 88% - completion--nth-completion > 10891 88% - seq-some > 10891 88% - seq-do > 10891 88% - mapc > 10891 88% - #<byte-code-function AC1> > 10891 88% - #<byte-code-function AD0> > 10891 88% - lsp-completion-passthrough-all-completions > 10891 88% - #<byte-code-function 4B5> > 10891 88% - #<byte-code-function 4DE> > 10888 88% - lsp-request-while-no-input > 10888 88% - sit-for > 82 0% + redisplay_internal (C function) > 18 0% + #<byte-code-function 31C> > 3 0% + lsp--text-document-position-params > 152 1% + redisplay > 89 0% + posn-at-point > 20 0% + corfu--candidates-popup > 674 5% + command-execute > 269 2% + redisplay_internal (C function) > 74 0% + #<byte-code-function 31C> > 59 0% + timer-event-handler > 25 0% + ... > > Please tell me if you need more information, While a Lisp profile is always a good thing to have, I suspect a C profile is more useful in this case. Can you run perf record -e instructions,cycles ./src/emacs -Q then find a problematic workflow and wait for the problem to occur (ideally, this will happen so often as to dominate the CPU trace), then quit emacs in the ordinary fashion. After that perf report will produce a basic output C profile. It's both very long and somewhat hard to read, but I think posting it to a bug number email should be okay. If you do this, please save these files for this specific run somewhere: ./src/emacs ./src/emacs.pdmp ./perf.data any coredumps you might have had This will allow us to investigate the situation further if the function names aren't enough to find the culprits. Please also attempt to find the precise version of "corfu", as well as any other packages that might seem like they're involved. Thanks! Pip
bug-gnu-emacs <at> gnu.org:bug#75922; Package emacs.
(Wed, 29 Jan 2025 13:08:02 GMT) Full text and rfc822 format available.Message #11 received at 75922 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Nicolas Sarlin <nico.sarlin <at> gmail.com> Cc: 75922 <at> debbugs.gnu.org Subject: Re: bug#75922: CPU hogs with pgtk Date: Wed, 29 Jan 2025 15:06:50 +0200
> From: Nicolas Sarlin <nico.sarlin <at> gmail.com> > Date: Wed, 29 Jan 2025 12:05:16 +0100 > > I'm using lsp-mode with corfu on the emacs-30 branch, and I get extremely > frequent CPU hogs (CPU runs at 100% for a few seconds) while typing > code. I report this as an emacs bug because it seems to only occurs when > emacs is compiled with pgtk. If I rebuild emacs with "make bootstrap > configure=default" the bug disapears. > > Here is a profiler record: > 11152 91% - corfu--post-command > 11152 91% - corfu--exhibit > 11043 90% - corfu--update > 10891 88% - corfu--recompute > 10891 88% - corfu--filter-completions > 10891 88% - completion-all-completions > 10891 88% - completion--nth-completion > 10891 88% - seq-some > 10891 88% - seq-do > 10891 88% - mapc > 10891 88% - #<byte-code-function AC1> > 10891 88% - #<byte-code-function AD0> > 10891 88% - lsp-completion-passthrough-all-completions > 10891 88% - #<byte-code-function 4B5> > 10891 88% - #<byte-code-function 4DE> > 10888 88% - lsp-request-while-no-input > 10888 88% - sit-for The profile says most of the time is spent in sit-for called from lsp-request-while-no-input. First, sit-for is not supposed to consume CPU, because it's a waiting function. Are you sure this profile was taken when Emacs was hogging CPU? And second, lsp-mode is not part of Emacs, so if indeed the above is a profile representative of high CPU load, I suggest to report this to the developers of lsp-mode first, even though the problem appears only in the PGTK build. Thanks.
bug-gnu-emacs <at> gnu.org:bug#75922; Package emacs.
(Wed, 29 Jan 2025 16:36:02 GMT) Full text and rfc822 format available.Message #14 received at 75922 <at> debbugs.gnu.org (full text, mbox):
From: Nicolas Sarlin <nico.sarlin <at> gmail.com> To: Pip Cet <pipcet <at> protonmail.com> Cc: 75922 <at> debbugs.gnu.org Subject: Re: bug#75922: CPU hogs with pgtk Date: Wed, 29 Jan 2025 16:28:01 +0100
Thanks for your answer!
On Wed, 29 Jan 2025 at 13:41, Pip Cet <pipcet <at> protonmail.com> wrote:
>
> "Nicolas Sarlin" <nico.sarlin <at> gmail.com> writes:
>
> Thanks for the report! Debug suggestions below, but if you cannot or
> would prefer not to any or all of that, that's perfectly okay, too!
>
> > I'm using lsp-mode with corfu on the emacs-30 branch, and I get extremely
> > frequent CPU hogs (CPU runs at 100% for a few seconds) while typing
> > code.
>
> So this happens on the pgtk branch, but behavior on the master branch is
> not noticeably slower than you'd expect?
This happens on the emacs-30 branch with configure=--with-pgtk
> > I report this as an emacs bug because it seems to only occurs when
> > emacs is compiled with pgtk.
>
> Are you running this on a Wayland setup, or on X (ignoring the popup)?
I am running this on Wayland
>
>
> > If I rebuild emacs with "make bootstrap configure=default" the bug
> > disapears.
>
> Entirely?
Yes, I see no slowdown at all without pgtk.
>
>
> > Here is a profiler record:
> > 11152 91% - corfu--post-command
> > 11152 91% - corfu--exhibit
> > 11043 90% - corfu--update
> > 10891 88% - corfu--recompute
> > 10891 88% - corfu--filter-completions
> > 10891 88% - completion-all-completions
> > 10891 88% - completion--nth-completion
> > 10891 88% - seq-some
> > 10891 88% - seq-do
> > 10891 88% - mapc
> > 10891 88% - #<byte-code-function AC1>
> > 10891 88% - #<byte-code-function AD0>
> > 10891 88% - lsp-completion-passthrough-all-completions
> > 10891 88% - #<byte-code-function 4B5>
> > 10891 88% - #<byte-code-function 4DE>
> > 10888 88% - lsp-request-while-no-input
> > 10888 88% - sit-for
> > 82 0% + redisplay_internal (C function)
> > 18 0% + #<byte-code-function 31C>
> > 3 0% + lsp--text-document-position-params
> > 152 1% + redisplay
> > 89 0% + posn-at-point
> > 20 0% + corfu--candidates-popup
> > 674 5% + command-execute
> > 269 2% + redisplay_internal (C function)
> > 74 0% + #<byte-code-function 31C>
> > 59 0% + timer-event-handler
> > 25 0% + ...
> >
> > Please tell me if you need more information,
>
> While a Lisp profile is always a good thing to have, I suspect a C
> profile is more useful in this case. Can you run
>
> perf record -e instructions,cycles ./src/emacs -Q
>
> then find a problematic workflow and wait for the problem to occur
> (ideally, this will happen so often as to dominate the CPU trace), then
> quit emacs in the ordinary fashion. After that
>
> perf report
>
> will produce a basic output C profile. It's both very long and somewhat
> hard to read, but I think posting it to a bug number email should be
> okay. If you do this, please save these files for this specific run
> somewhere:
>
> ./src/emacs
> ./src/emacs.pdmp
> ./perf.data
> any coredumps you might have had
>
> This will allow us to investigate the situation further if the function
> names aren't enough to find the culprits.
Thanks, here is a partial output of perf report, tell me if you need
more (events > 1%):
====
Samples: 1K of event 'cpu_atom/instructions/u', Event count (approx.):
1304155293
10,41% emacs emacs [.]
find_cache_boundary
◆
5,90% emacs emacs [.]
lookup_char_property
▒
4,71% emacs libpixman-1.so.0.44.2 [.]
0x000000000006f4c3
▒
3,33% emacs libpixman-1.so.0.44.2 [.]
0x000000000006f4d7
▒
3,01% emacs libpixman-1.so.0.44.2 [.]
0x00000000000733a2
▒
2,84% emacs libpixman-1.so.0.44.2 [.]
0x00000000000733d5
▒
2,61% emacs libpixman-1.so.0.44.2 [.]
0x000000000006f4df
▒
2,57% emacs emacs [.] find_newline
▒
2,20% emacs libpixman-1.so.0.44.2 [.]
0x00000000000733b8
▒
1,81% emacs libpixman-1.so.0.44.2 [.]
0x00000000000733af
▒
1,75% emacs emacs [.] read_char
▒
1,72% emacs emacs [.]
itree_iter_next_in_subtree
▒
1,65% emacs libpixman-1.so.0.44.2 [.]
0x00000000000733e1
▒
1,62% emacs libpixman-1.so.0.44.2 [.]
0x000000000006f4cf
▒
1,59% emacs libpixman-1.so.0.44.2 [.]
0x00000000000733cf
▒
1,56% emacs libpixman-1.so.0.44.2 [.]
0x00000000000733c5
▒
1,56% emacs emacs [.]
re_match_2_internal
▒
1,47% emacs libpixman-1.so.0.44.2 [.]
0x00000000000733aa
▒
1,42% emacs emacs [.] find_interval
▒
1,34% emacs [vdso] [.]
__vdso_clock_gettime
▒
1,21% emacs libpixman-1.so.0.44.2 [.]
0x00000000000733b6
▒
1,19% emacs emacs [.] Fassq
▒
1,18% emacs libpixman-1.so.0.44.2 [.]
0x00000000000733e4
▒
1,14% emacs libpixman-1.so.0.44.2 [.]
0x00000000000733d9
▒
1,10% emacs emacs [.]
gui_produce_glyphs
▒
1,05% emacs emacs [.]
bidi_resolve_explicit
====
Samples: 133K of event 'cpu_core/instructions/u', Event count
(approx.): 186403198903
21,55% emacs [vdso] [.]
__vdso_clock_gettime
20,07% emacs [unknown] [k] 0xffffffff9e200080
11,55% emacs emacs [.] read_char
4,31% emacs emacs [.] restore_getcjmp
2,87% emacs libpixman-1.so.0.44.2 [.] 0x00000000000733a2
2,47% emacs emacs [.]
quit_throw_to_read_char
2,16% emacs emacs [.] some_mouse_moved
1,94% emacs libc.so.6 [.] siglongjmp
1,89% emacs libc.so.6 [.] pthread_sigmask
1,75% emacs emacs [.] unbind_to
1,49% emacs emacs [.] EQ
1,33% emacs libc.so.6 [.] 0x00000000000925c6
1,32% emacs emacs [.] kbd_on_hold_p
1,25% emacs libc.so.6 [.] 0x00000000000925a5
1,19% emacs emacs [.] _longjmp <at> plt
1,18% emacs libc.so.6 [.] 0x0000000000092616
1,11% emacs emacs [.]
record_unwind_protect_ptr
1,10% emacs libpixman-1.so.0.44.2 [.] 0x00000000000733b8
1,08% emacs libc.so.6 [.] 0x000000000003cfaf
1,00% emacs emacs [.] pthread_sigmask <at> plt
====
Samples: 1K of event 'cpu_atom/cycles/u', Event count (approx.): 1083537627
22,42% emacs libpixman-1.so.0.44.2 [.] 0x000000000006f4c3
◆
13,33% emacs libpixman-1.so.0.44.2 [.]
0x000000000006f4d7
▒
9,30% emacs libpixman-1.so.0.44.2 [.]
0x000000000006f4df
▒
4,77% emacs emacs [.]
find_cache_boundary
▒
3,84% emacs libpixman-1.so.0.44.2 [.]
0x000000000006f4cf
▒
2,95% emacs libpixman-1.so.0.44.2 [.]
0x00000000000733a2
▒
2,34% emacs emacs [.]
lookup_char_property
▒
1,51% emacs libpixman-1.so.0.44.2 [.]
0x000000000006f4e3
▒
1,28% emacs libpixman-1.so.0.44.2 [.]
0x00000000000733b8
▒
1,23% emacs libpixman-1.so.0.44.2 [.]
0x000000000006f4d3
====
Samples: 140K of event 'cpu_core/cycles/u', Event count (approx.): 79660130854
16,86% emacs [vdso] [.]
__vdso_clock_gettime
13,66% emacs [unknown] [k] 0xffffffff9e200080
12,32% emacs emacs [.] read_char
6,88% emacs emacs [.] unbind_to
6,41% emacs libpixman-1.so.0.44.2 [.] 0x00000000000733a2
5,66% emacs libc.so.6 [.] pthread_sigmask
4,58% emacs emacs [.] restore_getcjmp
3,73% emacs libpixman-1.so.0.44.2 [.] 0x000000000006f4c3
2,64% emacs libpixman-1.so.0.44.2 [.] 0x000000000006f4db
2,22% emacs emacs [.]
quit_throw_to_read_char
1,90% emacs libpixman-1.so.0.44.2 [.] 0x000000000006f4e3
1,24% emacs emacs [.] some_mouse_moved
1,19% emacs libpixman-1.so.0.44.2 [.] 0x000000000006f4cb
1,08% emacs emacs [.]
record_unwind_protect_ptr
1,05% emacs emacs [.] current_timespec
>
> Please also attempt to find the precise version of "corfu", as well as
> any other packages that might seem like they're involved.
I am using corfu 1.7 from melpa-stable, and lsp-mode 20250129.601 from melpa
>
>
> Thanks!
> Pip
>
bug-gnu-emacs <at> gnu.org:bug#75922; Package emacs.
(Wed, 29 Jan 2025 16:36:02 GMT) Full text and rfc822 format available.Message #17 received at 75922 <at> debbugs.gnu.org (full text, mbox):
From: Nicolas Sarlin <nico.sarlin <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 75922 <at> debbugs.gnu.org Subject: Re: bug#75922: CPU hogs with pgtk Date: Wed, 29 Jan 2025 17:02:16 +0100
On Wed, 29 Jan 2025 at 14:06, Eli Zaretskii <eliz <at> gnu.org> wrote: > > > From: Nicolas Sarlin <nico.sarlin <at> gmail.com> > > Date: Wed, 29 Jan 2025 12:05:16 +0100 > > > > I'm using lsp-mode with corfu on the emacs-30 branch, and I get extremely > > frequent CPU hogs (CPU runs at 100% for a few seconds) while typing > > code. I report this as an emacs bug because it seems to only occurs when > > emacs is compiled with pgtk. If I rebuild emacs with "make bootstrap > > configure=default" the bug disapears. > > > > Here is a profiler record: > > 11152 91% - corfu--post-command > > 11152 91% - corfu--exhibit > > 11043 90% - corfu--update > > 10891 88% - corfu--recompute > > 10891 88% - corfu--filter-completions > > 10891 88% - completion-all-completions > > 10891 88% - completion--nth-completion > > 10891 88% - seq-some > > 10891 88% - seq-do > > 10891 88% - mapc > > 10891 88% - #<byte-code-function AC1> > > 10891 88% - #<byte-code-function AD0> > > 10891 88% - lsp-completion-passthrough-all-completions > > 10891 88% - #<byte-code-function 4B5> > > 10891 88% - #<byte-code-function 4DE> > > 10888 88% - lsp-request-while-no-input > > 10888 88% - sit-for > > The profile says most of the time is spent in sit-for called from > lsp-request-while-no-input. First, sit-for is not supposed to consume > CPU, because it's a waiting function. Are you sure this profile was > taken when Emacs was hogging CPU? > > And second, lsp-mode is not part of Emacs, so if indeed the above is a > profile representative of high CPU load, I suggest to report this to > the developers of lsp-mode first, even though the problem appears only > in the PGTK build. > > Thanks. Hi, thank you for your answer. Yes, this profile was collected during an emacs freeze. It took me a few second (maybe 10) after `profiler-start` to trigger the freeze, then again a few seconds of freeze, then I ran `profiler-stop` directly after. During the freeze I had one CPU core constantly running at 100%. I have seen a similar issue on lsp-mode closed so I tried to report it here: https://github.com/emacs-lsp/lsp-mode/issues/3720 Similarly to what is reported in the lsp issue, this only occurs for me when I mix lsp-mode, corfu and pgtk, so it's difficult to find the exact root cause.
bug-gnu-emacs <at> gnu.org:bug#75922; Package emacs.
(Wed, 29 Jan 2025 16:36:03 GMT) Full text and rfc822 format available.Message #20 received at 75922 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Nicolas Sarlin <nico.sarlin <at> gmail.com> Cc: 75922 <at> debbugs.gnu.org Subject: Re: bug#75922: CPU hogs with pgtk Date: Wed, 29 Jan 2025 18:35:06 +0200
> From: Nicolas Sarlin <nico.sarlin <at> gmail.com> > Date: Wed, 29 Jan 2025 17:02:16 +0100 > Cc: 75922 <at> debbugs.gnu.org > > On Wed, 29 Jan 2025 at 14:06, Eli Zaretskii <eliz <at> gnu.org> wrote: > > > > The profile says most of the time is spent in sit-for called from > > lsp-request-while-no-input. First, sit-for is not supposed to consume > > CPU, because it's a waiting function. Are you sure this profile was > > taken when Emacs was hogging CPU? > > > > And second, lsp-mode is not part of Emacs, so if indeed the above is a > > profile representative of high CPU load, I suggest to report this to > > the developers of lsp-mode first, even though the problem appears only > > in the PGTK build. > > > > Thanks. > > Hi, thank you for your answer. > Yes, this profile was collected during an emacs freeze. It took me a > few second (maybe 10) after `profiler-start` to trigger the freeze, > then again a few seconds of freeze, then I ran `profiler-stop` > directly after. During the freeze I had one CPU core constantly > running at 100%. But maybe the process which was consuming the CPU at that time was not Emacs? Because sit-for should not consume CPU, it just waits for some input (or for timeout). Is it possible that while Emacs waited, some other process, perhaps the LSP server itself, was spinning the CPU?
bug-gnu-emacs <at> gnu.org:bug#75922; Package emacs.
(Wed, 29 Jan 2025 17:30:02 GMT) Full text and rfc822 format available.Message #23 received at 75922 <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Nicolas Sarlin <nico.sarlin <at> gmail.com> Cc: Eli Zaretskii <eliz <at> gnu.org>, 75922 <at> debbugs.gnu.org Subject: Re: bug#75922: CPU hogs with pgtk Date: Wed, 29 Jan 2025 17:29:43 +0000
"Nicolas Sarlin" <nico.sarlin <at> gmail.com> writes:
> On Wed, 29 Jan 2025 at 14:06, Eli Zaretskii <eliz <at> gnu.org> wrote:
>>
>> > From: Nicolas Sarlin <nico.sarlin <at> gmail.com>
>> > Date: Wed, 29 Jan 2025 12:05:16 +0100
>> >
>> > I'm using lsp-mode with corfu on the emacs-30 branch, and I get extremely
>> > frequent CPU hogs (CPU runs at 100% for a few seconds) while typing
>> > code. I report this as an emacs bug because it seems to only occurs when
>> > emacs is compiled with pgtk. If I rebuild emacs with "make bootstrap
>> > configure=default" the bug disapears.
>> >
>> > Here is a profiler record:
>> > 11152 91% - corfu--post-command
>> > 11152 91% - corfu--exhibit
>> > 11043 90% - corfu--update
>> > 10891 88% - corfu--recompute
>> > 10891 88% - corfu--filter-completions
>> > 10891 88% - completion-all-completions
>> > 10891 88% - completion--nth-completion
>> > 10891 88% - seq-some
>> > 10891 88% - seq-do
>> > 10891 88% - mapc
>> > 10891 88% - #<byte-code-function AC1>
>> > 10891 88% - #<byte-code-function AD0>
>> > 10891 88% - lsp-completion-passthrough-all-completions
>> > 10891 88% - #<byte-code-function 4B5>
>> > 10891 88% - #<byte-code-function 4DE>
>> > 10888 88% - lsp-request-while-no-input
>> > 10888 88% - sit-for
>>
>> The profile says most of the time is spent in sit-for called from
>> lsp-request-while-no-input. First, sit-for is not supposed to consume
>> CPU, because it's a waiting function. Are you sure this profile was
>> taken when Emacs was hogging CPU?
>>
>> And second, lsp-mode is not part of Emacs, so if indeed the above is a
>> profile representative of high CPU load, I suggest to report this to
>> the developers of lsp-mode first, even though the problem appears only
>> in the PGTK build.
>>
>> Thanks.
>
> Hi, thank you for your answer.
> Yes, this profile was collected during an emacs freeze. It took me a
> few second (maybe 10) after `profiler-start` to trigger the freeze,
> then again a few seconds of freeze, then I ran `profiler-stop`
> directly after. During the freeze I had one CPU core constantly
> running at 100%.
My guess is it's this code in lsp-mode.el:
(while (not (or resp-error resp-result (input-pending-p)))
(catch 'lsp-done
(sit-for
(if expected-time (- expected-time send-time) 1)))
(setq send-time (float-time))
(when (and expected-time (< expected-time send-time))
(error "Timeout while waiting for response. Method: %s" method)))
This code appears to want to reliquish the CPU for the next
lsp-response-timeout (default 10) seconds, so it calls sit-for with an
argument close to 10.0, or 1 if no timeout is set.
The behavior of sit-for is to return immediately if there is pending
input, ignoring the timeout argument.
In this case, this loop will use all of the CPU until whatever it is
actually waiting for happens, assuming a single "input event" (a
keypress is one, but certain kinds of mouse movement or a similar event
can also cause sit-for to exit immediately) has happened.
Some other places also in that file may work less than optimally when
sit-for returns immediately, also.
So this seems most likely like a bug there, and it may be triggered more
by pgtk/wayland because of such details as key repeat being handled by
the application rather than what used to be the X server.
I'm slightly surprised at your perf report, but at least the last part
doesn't seem inconsistent with that interpretation.
Once the bug is fixed, it would be great to hear how the documentation
of sit-for could be improved. If that doesn't work, we might even want
to detect situations in which sit-for is called repeatedly with a
timeout argument even though no input was handled in the meantime.
Pip
bug-gnu-emacs <at> gnu.org:bug#75922; Package emacs.
(Thu, 30 Jan 2025 04:59:03 GMT) Full text and rfc822 format available.Message #26 received at 75922 <at> debbugs.gnu.org (full text, mbox):
From: Nicolas Sarlin <nico.sarlin <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 75922 <at> debbugs.gnu.org Subject: Re: bug#75922: CPU hogs with pgtk Date: Wed, 29 Jan 2025 17:49:15 +0100
On Wed, 29 Jan 2025 at 17:35, Eli Zaretskii <eliz <at> gnu.org> wrote: > > > From: Nicolas Sarlin <nico.sarlin <at> gmail.com> > > Date: Wed, 29 Jan 2025 17:02:16 +0100 > > Cc: 75922 <at> debbugs.gnu.org > > > > On Wed, 29 Jan 2025 at 14:06, Eli Zaretskii <eliz <at> gnu.org> wrote: > > > > > > The profile says most of the time is spent in sit-for called from > > > lsp-request-while-no-input. First, sit-for is not supposed to consume > > > CPU, because it's a waiting function. Are you sure this profile was > > > taken when Emacs was hogging CPU? > > > > > > And second, lsp-mode is not part of Emacs, so if indeed the above is a > > > profile representative of high CPU load, I suggest to report this to > > > the developers of lsp-mode first, even though the problem appears only > > > in the PGTK build. > > > > > > Thanks. > > > > Hi, thank you for your answer. > > Yes, this profile was collected during an emacs freeze. It took me a > > few second (maybe 10) after `profiler-start` to trigger the freeze, > > then again a few seconds of freeze, then I ran `profiler-stop` > > directly after. During the freeze I had one CPU core constantly > > running at 100%. > > But maybe the process which was consuming the CPU at that time was not > Emacs? Because sit-for should not consume CPU, it just waits for some > input (or for timeout). Is it possible that while Emacs waited, some > other process, perhaps the LSP server itself, was spinning the CPU? No I was speaking of the emacs process consuming cpu. Maybe there is some issue with how I collect the report. But I can reproduce it fairly easily, and every time I get a similar report (with emacs running at 100% during the freeze).
bug-gnu-emacs <at> gnu.org:bug#75922; Package emacs.
(Thu, 30 Jan 2025 04:59:04 GMT) Full text and rfc822 format available.Message #29 received at 75922 <at> debbugs.gnu.org (full text, mbox):
From: Nicolas Sarlin <nico.sarlin <at> gmail.com> To: Pip Cet <pipcet <at> protonmail.com> Cc: Eli Zaretskii <eliz <at> gnu.org>, 75922 <at> debbugs.gnu.org Subject: Re: bug#75922: CPU hogs with pgtk Date: Wed, 29 Jan 2025 23:30:55 +0100
[Message part 1 (text/plain, inline)]
On Wed, Jan 29, 2025, 18:29 Pip Cet <pipcet <at> protonmail.com> wrote: > "Nicolas Sarlin" <nico.sarlin <at> gmail.com> writes: > > > On Wed, 29 Jan 2025 at 14:06, Eli Zaretskii <eliz <at> gnu.org> wrote: > >> > >> > From: Nicolas Sarlin <nico.sarlin <at> gmail.com> > >> > Date: Wed, 29 Jan 2025 12:05:16 +0100 > >> > > >> > I'm using lsp-mode with corfu on the emacs-30 branch, and I get > extremely > >> > frequent CPU hogs (CPU runs at 100% for a few seconds) while typing > >> > code. I report this as an emacs bug because it seems to only occurs > when > >> > emacs is compiled with pgtk. If I rebuild emacs with "make bootstrap > >> > configure=default" the bug disapears. > >> > > >> > Here is a profiler record: > >> > 11152 91% - corfu--post-command > >> > 11152 91% - corfu--exhibit > >> > 11043 90% - corfu--update > >> > 10891 88% - corfu--recompute > >> > 10891 88% - corfu--filter-completions > >> > 10891 88% - completion-all-completions > >> > 10891 88% - completion--nth-completion > >> > 10891 88% - seq-some > >> > 10891 88% - seq-do > >> > 10891 88% - mapc > >> > 10891 88% - #<byte-code-function AC1> > >> > 10891 88% - #<byte-code-function AD0> > >> > 10891 88% - > lsp-completion-passthrough-all-completions > >> > 10891 88% - #<byte-code-function 4B5> > >> > 10891 88% - #<byte-code-function 4DE> > >> > 10888 88% - lsp-request-while-no-input > >> > 10888 88% - sit-for > >> > >> The profile says most of the time is spent in sit-for called from > >> lsp-request-while-no-input. First, sit-for is not supposed to consume > >> CPU, because it's a waiting function. Are you sure this profile was > >> taken when Emacs was hogging CPU? > >> > >> And second, lsp-mode is not part of Emacs, so if indeed the above is a > >> profile representative of high CPU load, I suggest to report this to > >> the developers of lsp-mode first, even though the problem appears only > >> in the PGTK build. > >> > >> Thanks. > > > > Hi, thank you for your answer. > > Yes, this profile was collected during an emacs freeze. It took me a > > few second (maybe 10) after `profiler-start` to trigger the freeze, > > then again a few seconds of freeze, then I ran `profiler-stop` > > directly after. During the freeze I had one CPU core constantly > > running at 100%. > > My guess is it's this code in lsp-mode.el: > > (while (not (or resp-error resp-result (input-pending-p))) > (catch 'lsp-done > (sit-for > (if expected-time (- expected-time send-time) 1))) > (setq send-time (float-time)) > (when (and expected-time (< expected-time send-time)) > (error "Timeout while waiting for response. Method: %s" > method))) > > This code appears to want to reliquish the CPU for the next > lsp-response-timeout (default 10) seconds, so it calls sit-for with an > argument close to 10.0, or 1 if no timeout is set. > > The behavior of sit-for is to return immediately if there is pending > input, ignoring the timeout argument. > > In this case, this loop will use all of the CPU until whatever it is > actually waiting for happens, assuming a single "input event" (a > keypress is one, but certain kinds of mouse movement or a similar event > can also cause sit-for to exit immediately) has happened. > > Some other places also in that file may work less than optimally when > sit-for returns immediately, also. > > So this seems most likely like a bug there, and it may be triggered more > by pgtk/wayland because of such details as key repeat being handled by > the application rather than what used to be the X server. > > I'm slightly surprised at your perf report, but at least the last part > doesn't seem inconsistent with that interpretation. > > Once the bug is fixed, it would be great to hear how the documentation > of sit-for could be improved. If that doesn't work, we might even want > to detect situations in which sit-for is called repeatedly with a > timeout argument even though no input was handled in the meantime. > > Pip Thank you for your help! I will report it to lsp-mode with the info you provided. Sorry for the disturbance
[Message part 2 (text/html, inline)]
bug-gnu-emacs <at> gnu.org:bug#75922; Package emacs.
(Thu, 30 Jan 2025 08:49:01 GMT) Full text and rfc822 format available.Message #32 received at 75922 <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Nicolas Sarlin <nico.sarlin <at> gmail.com> Cc: Eli Zaretskii <eliz <at> gnu.org>, 75922 <at> debbugs.gnu.org Subject: Re: bug#75922: CPU hogs with pgtk Date: Thu, 30 Jan 2025 08:48:12 +0000
"Nicolas Sarlin" <nico.sarlin <at> gmail.com> writes: > On Wed, Jan 29, 2025, 18:29 Pip Cet <pipcet <at> protonmail.com> wrote: > > "Nicolas Sarlin" <nico.sarlin <at> gmail.com> writes: > > > On Wed, 29 Jan 2025 at 14:06, Eli Zaretskii <eliz <at> gnu.org> wrote: > >> > >> > From: Nicolas Sarlin <nico.sarlin <at> gmail.com> > >> > Date: Wed, 29 Jan 2025 12:05:16 +0100 > >> > > >> > I'm using lsp-mode with corfu on the emacs-30 branch, and I get extremely > >> > frequent CPU hogs (CPU runs at 100% for a few seconds) while typing > >> > code. I report this as an emacs bug because it seems to only occurs when > >> > emacs is compiled with pgtk. If I rebuild emacs with "make bootstrap > >> > configure=default" the bug disapears. > >> > > >> > Here is a profiler record: > >> > 11152 91% - corfu--post-command > >> > 11152 91% - corfu--exhibit > >> > 11043 90% - corfu--update > >> > 10891 88% - corfu--recompute > >> > 10891 88% - corfu--filter-completions > >> > 10891 88% - completion-all-completions > >> > 10891 88% - completion--nth-completion > >> > 10891 88% - seq-some > >> > 10891 88% - seq-do > >> > 10891 88% - mapc > >> > 10891 88% - #<byte-code-function AC1> > >> > 10891 88% - #<byte-code-function AD0> > >> > 10891 88% - lsp-completion-passthrough-all-completions > >> > 10891 88% - #<byte-code-function 4B5> > >> > 10891 88% - #<byte-code-function 4DE> > >> > 10888 88% - lsp-request-while-no-input > >> > 10888 88% - sit-for > >> > >> The profile says most of the time is spent in sit-for called from > >> lsp-request-while-no-input. First, sit-for is not supposed to consume > >> CPU, because it's a waiting function. Are you sure this profile was > >> taken when Emacs was hogging CPU? > >> > >> And second, lsp-mode is not part of Emacs, so if indeed the above is a > >> profile representative of high CPU load, I suggest to report this to > >> the developers of lsp-mode first, even though the problem appears only > >> in the PGTK build. > >> > >> Thanks. > > > > Hi, thank you for your answer. > > Yes, this profile was collected during an emacs freeze. It took me a > > few second (maybe 10) after `profiler-start` to trigger the freeze, > > then again a few seconds of freeze, then I ran `profiler-stop` > > directly after. During the freeze I had one CPU core constantly > > running at 100%. > > My guess is it's this code in lsp-mode.el: > > (while (not (or resp-error resp-result (input-pending-p))) > (catch 'lsp-done > (sit-for > (if expected-time (- expected-time send-time) 1))) > (setq send-time (float-time)) > (when (and expected-time (< expected-time send-time)) > (error "Timeout while waiting for response. Method: %s" method))) > > This code appears to want to reliquish the CPU for the next > lsp-response-timeout (default 10) seconds, so it calls sit-for with an > argument close to 10.0, or 1 if no timeout is set. > > The behavior of sit-for is to return immediately if there is pending > input, ignoring the timeout argument. > > In this case, this loop will use all of the CPU until whatever it is > actually waiting for happens, assuming a single "input event" (a > keypress is one, but certain kinds of mouse movement or a similar event > can also cause sit-for to exit immediately) has happened. > > Some other places also in that file may work less than optimally when > sit-for returns immediately, also. > > So this seems most likely like a bug there, and it may be triggered more > by pgtk/wayland because of such details as key repeat being handled by > the application rather than what used to be the X server. > > I'm slightly surprised at your perf report, but at least the last part > doesn't seem inconsistent with that interpretation. > > Once the bug is fixed, it would be great to hear how the documentation > of sit-for could be improved. If that doesn't work, we might even want > to detect situations in which sit-for is called repeatedly with a > timeout argument even though no input was handled in the meantime. > > Pip > > Thank you for your help! I will report it to lsp-mode with the info you provided. > > Sorry for the disturbance No problem at all. I think the API is a bit confusing, and the documentation doesn't warn about it sufficiently. Both can be changed. Pip
Eli Zaretskii <eliz <at> gnu.org>:Nicolas Sarlin <nico.sarlin <at> gmail.com>:Message #37 received at 75922-done <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Pip Cet <pipcet <at> protonmail.com> Cc: nico.sarlin <at> gmail.com, 75922-done <at> debbugs.gnu.org Subject: Re: bug#75922: CPU hogs with pgtk Date: Sat, 08 Feb 2025 11:46:46 +0200
> Date: Thu, 30 Jan 2025 08:48:12 +0000 > From: Pip Cet <pipcet <at> protonmail.com> > Cc: Eli Zaretskii <eliz <at> gnu.org>, 75922 <at> debbugs.gnu.org > > "Nicolas Sarlin" <nico.sarlin <at> gmail.com> writes: > > > On Wed, Jan 29, 2025, 18:29 Pip Cet <pipcet <at> protonmail.com> wrote: > > > > "Nicolas Sarlin" <nico.sarlin <at> gmail.com> writes: > > > > > On Wed, 29 Jan 2025 at 14:06, Eli Zaretskii <eliz <at> gnu.org> wrote: > > >> > > >> > From: Nicolas Sarlin <nico.sarlin <at> gmail.com> > > >> > Date: Wed, 29 Jan 2025 12:05:16 +0100 > > >> > > > >> > I'm using lsp-mode with corfu on the emacs-30 branch, and I get extremely > > >> > frequent CPU hogs (CPU runs at 100% for a few seconds) while typing > > >> > code. I report this as an emacs bug because it seems to only occurs when > > >> > emacs is compiled with pgtk. If I rebuild emacs with "make bootstrap > > >> > configure=default" the bug disapears. > > >> > > > >> > Here is a profiler record: > > >> > 11152 91% - corfu--post-command > > >> > 11152 91% - corfu--exhibit > > >> > 11043 90% - corfu--update > > >> > 10891 88% - corfu--recompute > > >> > 10891 88% - corfu--filter-completions > > >> > 10891 88% - completion-all-completions > > >> > 10891 88% - completion--nth-completion > > >> > 10891 88% - seq-some > > >> > 10891 88% - seq-do > > >> > 10891 88% - mapc > > >> > 10891 88% - #<byte-code-function AC1> > > >> > 10891 88% - #<byte-code-function AD0> > > >> > 10891 88% - lsp-completion-passthrough-all-completions > > >> > 10891 88% - #<byte-code-function 4B5> > > >> > 10891 88% - #<byte-code-function 4DE> > > >> > 10888 88% - lsp-request-while-no-input > > >> > 10888 88% - sit-for > > >> > > >> The profile says most of the time is spent in sit-for called from > > >> lsp-request-while-no-input. First, sit-for is not supposed to consume > > >> CPU, because it's a waiting function. Are you sure this profile was > > >> taken when Emacs was hogging CPU? > > >> > > >> And second, lsp-mode is not part of Emacs, so if indeed the above is a > > >> profile representative of high CPU load, I suggest to report this to > > >> the developers of lsp-mode first, even though the problem appears only > > >> in the PGTK build. > > >> > > >> Thanks. > > > > > > Hi, thank you for your answer. > > > Yes, this profile was collected during an emacs freeze. It took me a > > > few second (maybe 10) after `profiler-start` to trigger the freeze, > > > then again a few seconds of freeze, then I ran `profiler-stop` > > > directly after. During the freeze I had one CPU core constantly > > > running at 100%. > > > > My guess is it's this code in lsp-mode.el: > > > > (while (not (or resp-error resp-result (input-pending-p))) > > (catch 'lsp-done > > (sit-for > > (if expected-time (- expected-time send-time) 1))) > > (setq send-time (float-time)) > > (when (and expected-time (< expected-time send-time)) > > (error "Timeout while waiting for response. Method: %s" method))) > > > > This code appears to want to reliquish the CPU for the next > > lsp-response-timeout (default 10) seconds, so it calls sit-for with an > > argument close to 10.0, or 1 if no timeout is set. > > > > The behavior of sit-for is to return immediately if there is pending > > input, ignoring the timeout argument. > > > > In this case, this loop will use all of the CPU until whatever it is > > actually waiting for happens, assuming a single "input event" (a > > keypress is one, but certain kinds of mouse movement or a similar event > > can also cause sit-for to exit immediately) has happened. > > > > Some other places also in that file may work less than optimally when > > sit-for returns immediately, also. > > > > So this seems most likely like a bug there, and it may be triggered more > > by pgtk/wayland because of such details as key repeat being handled by > > the application rather than what used to be the X server. > > > > I'm slightly surprised at your perf report, but at least the last part > > doesn't seem inconsistent with that interpretation. > > > > Once the bug is fixed, it would be great to hear how the documentation > > of sit-for could be improved. If that doesn't work, we might even want > > to detect situations in which sit-for is called repeatedly with a > > timeout argument even though no input was handled in the meantime. > > > > Pip > > > > Thank you for your help! I will report it to lsp-mode with the info you provided. > > > > Sorry for the disturbance > > No problem at all. I think the API is a bit confusing, and the > documentation doesn't warn about it sufficiently. Both can be changed. I think we can close this bug now.
Debbugs Internal Request <help-debbugs <at> gnu.org>
to internal_control <at> debbugs.gnu.org.
(Sat, 08 Mar 2025 12:24:08 GMT) Full text and rfc822 format available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.