GNU bug report logs - #76964
31.0.50; completion-preview-mode uses a lot of CPU

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 76964 in the body.
You can then email your comments to 76964 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Geza Herman <geza.herman <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; completion-preview-mode uses a lot of CPU
Date: Wed, 12 Mar 2025 00:08:05 +0100

When moving around a buffer with completion-preview-mode enabled, CPU 
usage becomes very high.

Profiling the problem reveals that with completion-preview-mode, 
redisplay_internal takes much more CPU.

The problem is in completion-preview--post-command, which calls 
(completion-preview-active-mode -1). For some reason, even though this 
should be a nop when just moving around a buffer, it forces emacs to do 
some more thorough redisplay. If I change this code to "(when 
completion-preview-active-mode (completion-preview-active-mode -1))", 
the problem goes away.

I think the problem is inside the define-minor-mode macro, because if I 
change completion-preview-active-mode to an empty minor mode definition:

(define-minor-mode completion-preview-active-mode
  "Mode for when the completion preview is shown."
  :interactive nil)

the problem still happens. Note: looking inside the define-minor-mode 
macro, I see a (force-mode-line-update) call. I'm not sure it's related, 
but it has a chance that it is.

In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, cairo version
 1.18.2) of 2025-03-11 built on okoska
Repository revision: 57f7d5f44a136c95958030b7920e5eca4b285309
Repository branch: HEAD
Windowing system distributor 'The X.Org Foundation', version 11.0.12101013
System Description: Debian GNU/Linux trixie/sid

Configured using:
 'configure --with-native-compilation --without-compress-install
 --without-gconf --without-gsettings --without-dbus --with-small-ja-dic
 --with-json --with-xinput2 --with-x-toolkit=no --with-tree-sitter
 --with-cairo --with-cairo-xcb --disable-silent-rules
 --disable-gc-mark-trace 'CFLAGS=-mtune=native -march=native -g3 -O3''

Configured features:
ACL CAIRO FREETYPE GIF GLIB GMP GNUTLS HARFBUZZ JPEG LCMS2 LIBOTF
LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP NOTIFY
INOTIFY OLDXMENU PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TREE_SITTER WEBP X11 XDBE XIM XINERAMA XINPUT2 XPM XRANDR ZLIB

Important settings:
  value of $LC_ALL: C.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=none
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  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
  minibuffer-regexp-mode: 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 compile comint ansi-osc ansi-color ring comp-run
bytecomp byte-compile comp-common rx emacsbug lisp-mnt message mailcap
yank-media puny dired dired-loaddefs rfc822 mml mml-sec password-cache
epa derived epg rfc6068 epg-config gnus-util text-property-search
time-date subr-x mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader cl-loaddefs cl-lib sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils rmc iso-transl tooltip
cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/x-win x-win term/common-win x-dnd touch-screen
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 inotify
lcms2 dynamic-setting font-render-setting cairo xinput2 x multi-tty
move-toolbar make-network-process tty-child-frames native-compile emacs)

Memory information:
((conses 16 85565 10951) (symbols 48 6794 0) (strings 32 23179 2179)
 (string-bytes 1 688051) (vectors 16 15115)
 (vector-slots 8 174583 11632) (floats 8 35 1) (intervals 56 332 0)
 (buffers 992 12))

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

From: Eshel Yaron <me <at> eshelyaron.com>
To: Geza Herman <geza.herman <at> gmail.com>
Cc: 76964 <at> debbugs.gnu.org
Subject: Re: bug#76964: 31.0.50; completion-preview-mode uses a lot of CPU
Date: Wed, 12 Mar 2025 07:48:38 +0100

Hi Geza,

Geza Herman <geza.herman <at> gmail.com> writes:

> When moving around a buffer with completion-preview-mode enabled, CPU
> usage becomes very high.
>
> Profiling the problem reveals that with completion-preview-mode,
> redisplay_internal takes much more CPU.
>
> The problem is in completion-preview--post-command, which calls
> (completion-preview-active-mode -1). For some reason, even though this
> should be a nop when just moving around a buffer, it forces emacs to
> do some more thorough redisplay. If I change this code to "(when
> completion-preview-active-mode (completion-preview-active-mode -1))",
> the problem goes away.
>
> I think the problem is inside the define-minor-mode macro, because if
> I change completion-preview-active-mode to an empty minor mode
> definition:
>
> (define-minor-mode completion-preview-active-mode
>   "Mode for when the completion preview is shown."
>   :interactive nil)
>
> the problem still happens. Note: looking inside the define-minor-mode
> macro, I see a (force-mode-line-update) call. I'm not sure it's
> related, but it has a chance that it is.

Thanks for investigating and reporting.  I think that conditioning the
(completion-preview-active-mode -1) in completion-preview--post-command
as you suggest makes sense.  Would you like to provide a simple patch
with that change?


Best,

Eshel

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

From: Eshel Yaron <me <at> eshelyaron.com>
To: Geza Herman <geza.herman <at> gmail.com>
Cc: 76964 <at> debbugs.gnu.org
Subject: Re: bug#76964: 31.0.50; completion-preview-mode uses a lot of CPU
Date: Sun, 16 Mar 2025 10:17:23 +0100

Eshel Yaron <me <at> eshelyaron.com> writes:

> Geza Herman <geza.herman <at> gmail.com> writes:
>
>> When moving around a buffer with completion-preview-mode enabled, CPU
>> usage becomes very high.
>>
>> Profiling the problem reveals that with completion-preview-mode,
>> redisplay_internal takes much more CPU.
>>
>> The problem is in completion-preview--post-command, which calls
>> (completion-preview-active-mode -1). For some reason, even though this
>> should be a nop when just moving around a buffer, it forces emacs to
>> do some more thorough redisplay. If I change this code to "(when
>> completion-preview-active-mode (completion-preview-active-mode -1))",
>> the problem goes away.
>>
>> I think the problem is inside the define-minor-mode macro, because if
>> I change completion-preview-active-mode to an empty minor mode
>> definition:
>>
>> (define-minor-mode completion-preview-active-mode
>>   "Mode for when the completion preview is shown."
>>   :interactive nil)
>>
>> the problem still happens. Note: looking inside the define-minor-mode
>> macro, I see a (force-mode-line-update) call. I'm not sure it's
>> related, but it has a chance that it is.
>
> Thanks for investigating and reporting.  I think that conditioning the
> (completion-preview-active-mode -1) in completion-preview--post-command
> as you suggest makes sense.  Would you like to provide a simple patch
> with that change?

I've now pushed such a change along with some additional commentary to
the emacs-30 branch in commit b6b4a080a3a.  It should make its way to
master soon enough.  Could you please check whether that improves
performance for you?


Thanks,

Eshel

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

From: Geza Herman <geza.herman <at> gmail.com>
To: Eshel Yaron <me <at> eshelyaron.com>
Cc: 76964 <at> debbugs.gnu.org
Subject: Re: bug#76964: 31.0.50; completion-preview-mode uses a lot of CPU
Date: Sun, 16 Mar 2025 16:49:04 +0100

Hi Eshel,

Thanks, the new version seems to work correctly!

(Sorry, I was meant to create a patch, for before that I asked a 
question in emacs-devel about the behavior of define-minor-mode, and I 
was waiting for a response - got none so far)

Geza


On 3/16/25 10:17 AM, Eshel Yaron wrote:
> Eshel Yaron <me <at> eshelyaron.com> writes:
>
>> Geza Herman <geza.herman <at> gmail.com> writes:
>>
>>> When moving around a buffer with completion-preview-mode enabled, CPU
>>> usage becomes very high.
>>>
>>> Profiling the problem reveals that with completion-preview-mode,
>>> redisplay_internal takes much more CPU.
>>>
>>> The problem is in completion-preview--post-command, which calls
>>> (completion-preview-active-mode -1). For some reason, even though this
>>> should be a nop when just moving around a buffer, it forces emacs to
>>> do some more thorough redisplay. If I change this code to "(when
>>> completion-preview-active-mode (completion-preview-active-mode -1))",
>>> the problem goes away.
>>>
>>> I think the problem is inside the define-minor-mode macro, because if
>>> I change completion-preview-active-mode to an empty minor mode
>>> definition:
>>>
>>> (define-minor-mode completion-preview-active-mode
>>>    "Mode for when the completion preview is shown."
>>>    :interactive nil)
>>>
>>> the problem still happens. Note: looking inside the define-minor-mode
>>> macro, I see a (force-mode-line-update) call. I'm not sure it's
>>> related, but it has a chance that it is.
>> Thanks for investigating and reporting.  I think that conditioning the
>> (completion-preview-active-mode -1) in completion-preview--post-command
>> as you suggest makes sense.  Would you like to provide a simple patch
>> with that change?
> I've now pushed such a change along with some additional commentary to
> the emacs-30 branch in commit b6b4a080a3a.  It should make its way to
> master soon enough.  Could you please check whether that improves
> performance for you?
>
>
> Thanks,
>
> Eshel
>

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

From: Eshel Yaron <me <at> eshelyaron.com>
To: Geza Herman <geza.herman <at> gmail.com>
Cc: 76964 <at> debbugs.gnu.org
Subject: Re: bug#76964: 31.0.50; completion-preview-mode uses a lot of CPU
Date: Sun, 16 Mar 2025 19:14:51 +0100

close 76964 30.2
quit

Geza Herman <geza.herman <at> gmail.com> writes:

> Hi Eshel,
>
> Thanks, the new version seems to work correctly!

Great, thanks for confirming.

> (Sorry, I was meant to create a patch, for before that I asked a
> question in emacs-devel about the behavior of define-minor-mode, and I
> was waiting for a response - got none so far)

Oh, I missed that message.  Indeed, if we end up changing
define-minor-mode then we'll be able remove this check in
completion-preview--post-command.  For now, I'm closing this bug.


Thanks again,

Eshel

Previous Next

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