GNU bug report logs - #73046
29.4; Emacs 100% CPU usage for several seconds when opening dired buffer over TRAMP

Previous Next

Full log

Message #104 received at 73046 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Suhail Singh <suhailsingh247 <at> gmail.com>
Cc: michael.albinus <at> gmx.de, suhailsingh247 <at> gmail.com, 73046 <at> debbugs.gnu.org
Subject: Re: bug#73046: 29.4; Emacs 100% CPU usage for several seconds when
 opening dired buffer over TRAMP
Date: Sun, 08 Sep 2024 20:53:46 +0300

> From: Suhail Singh <suhailsingh247 <at> gmail.com>
> Cc: Michael Albinus <michael.albinus <at> gmx.de>,  suhailsingh247 <at> gmail.com,
>   73046 <at> debbugs.gnu.org
> Date: Sun, 08 Sep 2024 12:46:39 -0400
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Waiting for a process to respond should try not to spin without
> > sleeping for a few milliseconds between polling attempts.
> 
> A constant delay busy-wait would be better than what's there today.

It isn't a delay, or at least the delay is not the main point.  The
main point is to yield the CPU, and that usually has dramatic effect
on CPU load.

> However, I thought you'd be proposing something like registering a
> "callback".  Out of curiosity, since I am unfamiliar with the relevant
> Emacs internals, would it not be possible to add a function to the
> equivalent of `after-change-functions' that processes the output?

accept-process-output already does that.  Except that with a timeout
of zero, it just checks whether any output arrived, and if not,
returns immediately.  Adding a timeout will AFAIU cause us to let the
OS preempt our execution thread and reschedule it only if no output
arrives during the timeout.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.