bug#37000: 27.0.50; gc and laggy Emacs

bug#37000: 27.0.50; gc and laggy Emacs

[Alex Branham]

Hello -

Recently I've noticed Emacs sometimes getting _very_ laggy, as in 
taking up to a half-second to display the a single character that 
I type. M-x profiler-start suggests that garbage-collection is 
taking up too much time (see below my signature for example 
output). gc-cons-percentage and gc-cons-threshold are at their 
default values. I can't figure out how to reproduce this reliably, 
but running M-x relint-directory on the Emacs source tree seems to 
do a decent job triggering it. My Emacs is built from commit 
4ce9c6d0b58bd77bc811d6c1c5caf955a5a0be2f (~ 4 days ago) of the 
master branch. How can I go about tracking this down?

Thanks,
Alex

- ... 
  51442  74%
   Automatic GC 
   51440  74%
 + winum-select-window-1 
 1   0%
 + #<compiled 0x443aa1> 
 1   0%
+ command-execute 
11973  17%
+ timer-event-handler 
4837   6%
+ flyspell-post-command-hook 
536   0%
+ redisplay_internal (C function) 
262   0%
+ xcb:-connection-filter 
60   0%
+ internal-timer-start-idle 
38   0%
  mu4e~proc-filter 
  11   0%
+ winner-save-old-configurations 
6   0%
+ eldoc-pre-command-refresh-echo-area 
4   0%
+ #<compiled 0x1ffab289c50b> 
3   0%
+ undo-auto--add-boundary 
1   0%
  exwm-layout--on-echo-area-change 
  1   0%
+ mu4e~update-sentinel-func 
1   0%
+ gui-set-selection 
1   0%
+ #<compiled 0x10b7815> 
1   0%



In GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 
3.24.10)
Windowing system distributor 'The X.Org Foundation', version 
11.0.12004000
System Description: NixOS 19.03.173251.56d94c8c69f (Koi)

Configured using:
 'configure
 --prefix=/nix/store/zwkzz533szjmra431czdyr39hibfzxni-emacs-27.0.50
 --disable-build-details --with-modules --with-x-toolkit=gtk3 
 --with-xft
 CFLAGS=-DMAC_OS_X_VERSION_MAX_ALLOWED=101200'
Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND DBUS GSETTINGS GLIB NOTIFY 
INOTIFY
LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF XFT 
ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD 
JSON
PDUMPER GMP
Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Memory information:
((conses 16 678039 134311)
 (symbols 48 88978 26)
 (strings 32 245611 6884)
 (string-bytes 1 7634214)
 (vectors 16 142349)
 (vector-slots 8 3015732 58606)
 (floats 8 741 448)
 (intervals 56 9225 1373)
 (buffers 992 1263))

bug#37000: 27.0.50; gc and laggy Emacs

[Eli Zaretskii]

> From: Alex Branham <alex.branham@gmail.com>
> Date: Sat, 10 Aug 2019 11:27:29 -0500
> 
> Recently I've noticed Emacs sometimes getting _very_ laggy, as in 
> taking up to a half-second to display the a single character that 
> I type. M-x profiler-start suggests that garbage-collection is 
> taking up too much time (see below my signature for example 
> output). gc-cons-percentage and gc-cons-threshold are at their 
> default values. I can't figure out how to reproduce this reliably, 
> but running M-x relint-directory on the Emacs source tree seems to 
> do a decent job triggering it. My Emacs is built from commit 
> 4ce9c6d0b58bd77bc811d6c1c5caf955a5a0be2f (~ 4 days ago) of the 
> master branch. How can I go about tracking this down?

Trying to bisect to find the offending commit would be one way.

bug#37000: 27.0.50; gc and laggy Emacs

[Alex Branham]

On Sat 10 Aug 2019 at 19:50, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Alex Branham <alex.branham@gmail.com>
>> Date: Sat, 10 Aug 2019 11:27:29 -0500
>> 
>> Recently I've noticed Emacs sometimes getting _very_ laggy, as in 
>> taking up to a half-second to display the a single character that 
>> I type. M-x profiler-start suggests that garbage-collection is 
>> taking up too much time (see below my signature for example 
>> output). gc-cons-percentage and gc-cons-threshold are at their 
>> default values. I can't figure out how to reproduce this reliably, 
>> but running M-x relint-directory on the Emacs source tree seems to 
>> do a decent job triggering it. My Emacs is built from commit 
>> 4ce9c6d0b58bd77bc811d6c1c5caf955a5a0be2f (~ 4 days ago) of the 
>> master branch. How can I go about tracking this down?
>
> Trying to bisect to find the offending commit would be one way.

Thanks. I noticed there's some activity around gc on master currently.
I'll wait for that to pass before trying this.

I'll note though that I don't see this issue on 26.2.

Alex

bug#37000: 27.0.50; gc and laggy Emacs

[Eli Zaretskii]

> From: Alex Branham <alex.branham@gmail.com>
> Cc: 37000@debbugs.gnu.org
> Date: Thu, 15 Aug 2019 09:56:44 -0500
> 
> >> Recently I've noticed Emacs sometimes getting _very_ laggy, as in 
> >> taking up to a half-second to display the a single character that 
> >> I type. M-x profiler-start suggests that garbage-collection is 
> >> taking up too much time (see below my signature for example 
> >> output). gc-cons-percentage and gc-cons-threshold are at their 
> >> default values. I can't figure out how to reproduce this reliably, 
> >> but running M-x relint-directory on the Emacs source tree seems to 
> >> do a decent job triggering it. My Emacs is built from commit 
> >> 4ce9c6d0b58bd77bc811d6c1c5caf955a5a0be2f (~ 4 days ago) of the 
> >> master branch. How can I go about tracking this down?
> >
> > Trying to bisect to find the offending commit would be one way.
> 
> Thanks. I noticed there's some activity around gc on master currently.
> I'll wait for that to pass before trying this.

Unless you happen to set gc-cons-threshold to a large value, that
activity is already over.  And in any case, invoking
garbage-collection manually should "fix" the lagging, if it somehow
related to what we are still discussing.

bug#37000: 27.0.50; gc and laggy Emacs

[Stefan Kangas]

Alex Branham <alex.branham@gmail.com> writes:

> On Sat 10 Aug 2019 at 19:50, Eli Zaretskii <eliz@gnu.org> wrote:
>
>>> From: Alex Branham <alex.branham@gmail.com>
>>> Date: Sat, 10 Aug 2019 11:27:29 -0500
>>>
>>> Recently I've noticed Emacs sometimes getting _very_ laggy, as in
>>> taking up to a half-second to display the a single character that
>>> I type. M-x profiler-start suggests that garbage-collection is
>>> taking up too much time (see below my signature for example
>>> output). gc-cons-percentage and gc-cons-threshold are at their
>>> default values. I can't figure out how to reproduce this reliably,
>>> but running M-x relint-directory on the Emacs source tree seems to
>>> do a decent job triggering it. My Emacs is built from commit
>>> 4ce9c6d0b58bd77bc811d6c1c5caf955a5a0be2f (~ 4 days ago) of the
>>> master branch. How can I go about tracking this down?
>>
>> Trying to bisect to find the offending commit would be one way.
>
> Thanks. I noticed there's some activity around gc on master currently.
> I'll wait for that to pass before trying this.
>
> I'll note though that I don't see this issue on 26.2.

(That was one year ago.)

Any updates here?

bug#37000: 27.0.50; gc and laggy Emacs

[Alex Branham]

On Tue 25 Aug 2020 at 17:15, Stefan Kangas <stefan@marxist.se> wrote:

> Alex Branham <alex.branham@gmail.com> writes:
>
>> On Sat 10 Aug 2019 at 19:50, Eli Zaretskii <eliz@gnu.org> wrote:
>>
>>>> From: Alex Branham <alex.branham@gmail.com>
>>>> Date: Sat, 10 Aug 2019 11:27:29 -0500
>>>>
>>>> Recently I've noticed Emacs sometimes getting _very_ laggy, as in
>>>> taking up to a half-second to display the a single character that
>>>> I type. M-x profiler-start suggests that garbage-collection is
>>>> taking up too much time (see below my signature for example
>>>> output). gc-cons-percentage and gc-cons-threshold are at their
>>>> default values. I can't figure out how to reproduce this reliably,
>>>> but running M-x relint-directory on the Emacs source tree seems to
>>>> do a decent job triggering it. My Emacs is built from commit
>>>> 4ce9c6d0b58bd77bc811d6c1c5caf955a5a0be2f (~ 4 days ago) of the
>>>> master branch. How can I go about tracking this down?
>>>
>>> Trying to bisect to find the offending commit would be one way.
>>
>> Thanks. I noticed there's some activity around gc on master currently.
>> I'll wait for that to pass before trying this.
>>
>> I'll note though that I don't see this issue on 26.2.
>
> (That was one year ago.)
>
> Any updates here?

No, but the problem seems to have gone away so I'll close this bug.