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 #161 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, 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: Sat, 14 Sep 2024 18:03:19 +0300

> From: Suhail Singh <suhailsingh247 <at> gmail.com>
> Cc: Suhail Singh <suhailsingh247 <at> gmail.com>,  michael.albinus <at> gmx.de,
>   73046 <at> debbugs.gnu.org
> Date: Sat, 14 Sep 2024 10:25:13 -0400
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> 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).
> >> 
> >> Thoughts?
> >
> > Are 2 and 3 new with this patch, or were they present in the previous
> > code as well?
> 
> Present prior to the patch as well.
> 
> > And what do you expect to happen when you press M-x while Emacs is
> > still busy performing your previous command?
> 
> I did not have any expectations wrt 2.  I knew that it was possible that
> 2 was simply a limitation of the single-threaded reality of the current
> implementation.  However, it wasn't clear (till now) whether that was
> necessarily the case.
> 
> 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.

In any case, interrupting the wait when you type makes sense in
general: it means Emacs is expected to respond sooner, which in most
cases indeed means to stop waiting immediately.

Previous Next

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