--- Begin Message ---
|
Subject: |
29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP |
|
Date: |
Thu, 05 Sep 2024 10:24:54 -0400 |
I observe 100% CPU usage for several seconds when invoking dired for a
directory on one of the remote machines I connect to. This doesn't seem
to happen for another host. The connection to the affected host is
slower, and on that host the issue is worse when the directory has
several symlinks.
To reproduce via =emacs -Q=:
- Invoke `find-file' and connect to problematic host over ssh.
- Once connection is established, open dired pointing to a directory on
the affected host.
- Observe bug: it takes _several_ seconds for the dired buffer to show.
During that time, Emacs CPU usage is 100%.
- Once dired buffer is open, invoke `revert-buffer' and observe issue
again.
Disabling global-font-lock-mode, makes the situation better.
Given that rudimentary font-locking should be possible via, simply, the
output of `ls --dired', it is unclear why enabling font-locking makes
things so much worse. If there are some aspects of font-locking that
perform much worse over a slower connection, it would help if there were
a user configuration to disable them.
It would also help if being over a slow connection didn't result in
Emacs consuming 100% of the CPU via functions such as
`tramp-wait-for-regexp' (based on profiler-report). Could some of this
be done asynchronously?
In GNU Emacs 29.4 (build 2, x86_64-suse-linux-gnu, GTK+ Version 3.24.43,
cairo version 1.18.0)
System Description: openSUSE Tumbleweed
Configured using:
'configure --disable-build-details --without-pop --with-mailutils
--with-native-compilation --without-hesiod --with-gameuser=:games
--with-kerberos --with-kerberos5 --with-file-notification=inotify
--with-modules --enable-autodepend --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share
--localstatedir=/var --sharedstatedir=/var/lib
--libexecdir=/usr/libexec --with-file-notification=yes
--libdir=/usr/lib64
--enable-locallisppath=/usr/share/emacs/29.4/site-lisp:/usr/share/emacs/site-lisp
--with-x --with-xim --with-sound --with-xpm --with-jpeg --with-tiff
--with-gif --with-png --with-rsvg --with-dbus --with-webp --with-xft
--with-imagemagick --without-gpm --with-x-toolkit=gtk3 --with-pgtk
--with-toolkit-scroll-bars --x-includes=/usr/include
--x-libraries=/usr/lib64 --with-libotf --with-m17n-flt --with-cairo
--with-xwidgets --build=x86_64-suse-linux --with-dumping=pdumper
'CFLAGS=-O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3
-fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables
-fstack-clash-protection -Werror=return-type -flto=auto -g
-D_GNU_SOURCE -DGDK_DISABLE_DEPRECATION_WARNINGS
-DGLIB_DISABLE_DEPRECATION_WARNINGS -pipe -Wno-pointer-sign
-Wno-unused-variable -Wno-unused-label -fno-optimize-sibling-calls
-DPDMP_BASE='\''"emacs-wayland"'\''' LDFLAGS=-Wl,-O2'
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ
IMAGEMAGICK JPEG JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 MODULES
NATIVE_COMP NOTIFY INOTIFY PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3
THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM XWIDGETS GTK3 ZLIB
Important settings:
value of $LC_NUMERIC: POSIX
value of $LC_TIME: en_US.UTF-8
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: Dired by name
Minor modes in effect:
shell-dirtrack-mode: t
tooltip-mode: t
global-eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
buffer-read-only: t
line-number-mode: t
indent-tabs-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny rfc822
mml mml-sec epa derived epg rfc6068 epg-config gnus-util
text-property-search mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils dired-aux dired dired-loaddefs tramp-sh
tramp-cache time-stamp tramp tramp-loaddefs trampver tramp-integration
files-x tramp-compat rx shell pcomplete comint ansi-osc ring parse-time
iso8601 time-date format-spec auth-source cl-seq eieio eieio-core
cl-macs cl-loaddefs cl-lib password-cache json subr-x map byte-opt gv
bytecomp byte-compile ansi-color rmc delsel lpr easy-mmode pcase
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 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 xwidget-internal dbusbind inotify dynamic-setting
system-font-setting font-render-setting cairo gtk pgtk lcms2 multi-tty
make-network-process native-compile emacs)
Memory information:
((conses 16 94415 10209)
(symbols 48 8472 0)
(strings 32 27423 1593)
(string-bytes 1 934096)
(vectors 16 17482)
(vector-slots 8 388602 12097)
(floats 8 33 35)
(intervals 56 549 0)
(buffers 984 12))
--
Suhail
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#73046: 29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP |
|
Date: |
Sat, 21 Sep 2024 10:30:28 +0200 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Version: 31.1
Michael Albinus <michael.albinus@gmx.de> writes:
Hi Suhail,
>> On a related, but distinct note, thoughts on whether there's a
>> relatively straightforward way to address "3" below (from one of the
>> other exchanges in this thread)?
>>
>>>> >> 3. If after invoking M-x we immediately start typing, the keyboard input
>>>> >> is registered, however, it doesn't display in the minibuffer till
>>>> >> after the offending directory has finished font-locking.
>>>> >> Additionally, doing so invariably results in 100% CPU usage for the
>>>> >> duration of the font-locking. Sometimes invoking M-x alone results
>>>> >> in CPU usage going back up to 100% (while font-locking is still being
>>>> >> done).
>>>>
>>>> > And what do you expect to happen when you press M-x while Emacs is
>>>> > still busy performing your previous command?
>>>>
>>>> I did not expect 3 to happen. I.e., wrt 3 my expectation was that
>>>> invoking M-x and typing doesn't result in a noticable increase in CPU
>>>> usage for the duration of the font-locking.
>>>
>>> If 3 surprised you, then the reason is simple: sit-for returns
>>> immediately if any input is available, so typing effectively disables
>>> the wait. This could be countermanded by unconditional sleep, but
>>> AFAIU Michael is rethinking the whole issue, so we should wait for him
>>> to reach his conclusions.
>
> This would mean to use (sleep-for 0) instead of (sit-for 0), right? Hmm,
> I might try the same tests for this clause next days, no idea whether it
> makes a difference.
>
> But ATM, we should use (sit-for 0), until we know better.
I've tried (sleep-for 0), but this doesn't help. CPU load is always 100%,
even if there is no input.
So I've pushed (sit-for 0) to master. Unless Eli has a better proposal,
I'm done with this.
It will also be available in Tramp 2.7.1.3, scheduled for release on GNU
ELPA end of this month.
Closing the bug.
Best regards, Michael.
--- End Message ---