Subject: Re: bug#73046: 29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP

From: Suhail Singh <[email-masked]>
Date: Fri, 06 Sep 2024 13:47:54 -0400

Eli Zaretskii <[email-masked]> writes:

> I think we should also try to establish how slow is that connection.
> How much time does "ping" take?

The server doesn't respond to "ping" requests so I cannot test that.
There are however more than 14 hops as reported by mtr.  How much more I
cannot say, unfortunately.

> How long does it take to fetch a file of, say 20 KBytes?

Given a 20kb file generated via:
#+begin_src sh :results verbatim
  mkdir -p /tmp/test
  cd /tmp/test
  dd if=/dev/urandom of=upload_test bs=10k count=2
  du -sh /tmp/test/upload_test
#+end_src

#+RESULTS:
: 20K	/tmp/test/upload_test

It takes ~4-6s to upload:
#+begin_src sh :results verbatim
  cd /tmp/test
  {
      time scp upload_test scp://${affected-host}//tmp/upload_test
  } 2>&1
#+end_src

#+RESULTS:
: 
: real	0m4.255s
: user	0m0.008s
: sys	0m0.002s

And a similar time to download:
#+begin_src sh :results verbatim
  cd /tmp/test
  {
      time scp scp://${affected-host}//tmp/upload_test ./download_test
  } 2>&1
#+end_src

#+RESULTS:
: 
: real	0m5.638s
: user	0m0.007s
: sys	0m0.000s

> Also, if font-lock is disabled, does the problem go away?

As noted in the original message:

>>> Disabling global-font-lock-mode, makes the situation better.

Things are still sluggish after disabling font-lock, but they are *much*
better (i.e., instead of a ~10s delay for revert-buffer we are down to
less than a second).  The remaining sluggishness seems reasonable given
what I know about the connection speed, but I have not done extensive
quantitative testing.  As such, while I cannot say with certainty if
"the problem" goes away entirely, or only mostly, it does improve
significantly.

-- 
Suhail