GNU bug report logs -
#37000
27.0.50; gc and laggy Emacs
Previous Next
Reported by: Alex Branham <alex.branham <at> gmail.com>
Date: Sat, 10 Aug 2019 16:28:02 UTC
Severity: normal
Found in version 27.0.50
Done: Alex Branham <alex.branham <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 37000 in the body.
You can then email your comments to 37000 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37000
; Package
emacs
.
(Sat, 10 Aug 2019 16:28:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Alex Branham <alex.branham <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sat, 10 Aug 2019 16:28:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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))
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37000
; Package
emacs
.
(Sat, 10 Aug 2019 16:52:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 37000 <at> debbugs.gnu.org (full text, mbox):
> From: Alex Branham <alex.branham <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37000
; Package
emacs
.
(Thu, 15 Aug 2019 14:57:03 GMT)
Full text and
rfc822 format available.
Message #11 received at 37000 <at> debbugs.gnu.org (full text, mbox):
On Sat 10 Aug 2019 at 19:50, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Alex Branham <alex.branham <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37000
; Package
emacs
.
(Thu, 15 Aug 2019 15:35:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 37000 <at> debbugs.gnu.org (full text, mbox):
> From: Alex Branham <alex.branham <at> gmail.com>
> Cc: 37000 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37000
; Package
emacs
.
(Wed, 26 Aug 2020 00:16:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 37000 <at> debbugs.gnu.org (full text, mbox):
Alex Branham <alex.branham <at> gmail.com> writes:
> On Sat 10 Aug 2019 at 19:50, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>>> From: Alex Branham <alex.branham <at> 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?
Reply sent
to
Alex Branham <alex.branham <at> gmail.com>
:
You have taken responsibility.
(Thu, 27 Aug 2020 20:58:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Alex Branham <alex.branham <at> gmail.com>
:
bug acknowledged by developer.
(Thu, 27 Aug 2020 20:58:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 37000-done <at> debbugs.gnu.org (full text, mbox):
On Tue 25 Aug 2020 at 17:15, Stefan Kangas <stefan <at> marxist.se> wrote:
> Alex Branham <alex.branham <at> gmail.com> writes:
>
>> On Sat 10 Aug 2019 at 19:50, Eli Zaretskii <eliz <at> gnu.org> wrote:
>>
>>>> From: Alex Branham <alex.branham <at> 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.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 25 Sep 2020 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 185 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.