GNU bug report logs - #51734
29.0.50; got slow

Previous Next

Package: emacs;

Reported by: Katsumi Yamaoka <yamaoka <at> jpl.org>

Date: Wed, 10 Nov 2021 00:37:01 UTC

Severity: normal

Found in version 29.0.50

Done: Ken Brown <kbrown <at> cornell.edu>

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 51734 in the body.
You can then email your comments to 51734 AT debbugs.gnu.org in the normal way.

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#51734; Package emacs. (Wed, 10 Nov 2021 00:37:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Katsumi Yamaoka <yamaoka <at> jpl.org>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Wed, 10 Nov 2021 00:37:02 GMT) Full text and rfc822 format available.

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

From: Katsumi Yamaoka <yamaoka <at> jpl.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; got slow
Date: Wed, 10 Nov 2021 09:36:14 +0900
Hi,

I'm sorry for my ambiguous report, but the redisplay or the cursor
movement on an Emacs screen got awkward and slow recently.  This
happens on Emacs git master built on 64-bit Cygwin.
For instance, the cursor moves not smoothly while repeating `C-n's,
`C-s' takes a couple of seconds for the text searched to appear, etc.
It should have happened after my build on Thu 4 Nov 22:00 UTC
through the previous build on Mon 8 Nov 22:00 UTC.

Thanks.

In GNU Emacs 29.0.50 (build 1, x86_64-pc-cygwin, GTK+ Version 3.22.28, cairo version 1.17.4)
 of 2021-11-10 built on localhost
Windowing system distributor 'The Cygwin/X Project', version 11.0.12012000
Configured using:
 'configure 'CFLAGS=-O0 -g3' --verbose --with-x-toolkit=gtk3
 --with-imagemagick'




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51734; Package emacs. (Wed, 10 Nov 2021 12:39:02 GMT) Full text and rfc822 format available.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Katsumi Yamaoka <yamaoka <at> jpl.org>
Cc: 51734 <at> debbugs.gnu.org
Subject: Re: bug#51734: 29.0.50; got slow
Date: Wed, 10 Nov 2021 20:38:32 +0800
Katsumi Yamaoka <yamaoka <at> jpl.org> writes:

> I'm sorry for my ambiguous report, but the redisplay or the cursor
> movement on an Emacs screen got awkward and slow recently.  This
> happens on Emacs git master built on 64-bit Cygwin.
> For instance, the cursor moves not smoothly while repeating `C-n's,
> `C-s' takes a couple of seconds for the text searched to appear, etc.
> It should have happened after my build on Thu 4 Nov 22:00 UTC
> through the previous build on Mon 8 Nov 22:00 UTC.
>
> Thanks.

See below.

>  'configure 'CFLAGS=-O0 -g3' --verbose --with-x-toolkit=gtk3
>  --with-imagemagick'

Did you notice the problem in the Emacs in which you ran
`report-emacs-bug'?  `-O0 -g3' will normally slow down Emacs
considerably, as it disables all compiler optimizations, and is used as
a debugging aid.

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51734; Package emacs. (Wed, 10 Nov 2021 12:54:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Katsumi Yamaoka <yamaoka <at> jpl.org>
Cc: 51734 <at> debbugs.gnu.org
Subject: Re: bug#51734: 29.0.50; got slow
Date: Wed, 10 Nov 2021 14:53:00 +0200
> Date: Wed, 10 Nov 2021 09:36:14 +0900
> From: Katsumi Yamaoka <yamaoka <at> jpl.org>
> 
> I'm sorry for my ambiguous report, but the redisplay or the cursor
> movement on an Emacs screen got awkward and slow recently.  This
> happens on Emacs git master built on 64-bit Cygwin.
> For instance, the cursor moves not smoothly while repeating `C-n's,
> `C-s' takes a couple of seconds for the text searched to appear, etc.
> It should have happened after my build on Thu 4 Nov 22:00 UTC
> through the previous build on Mon 8 Nov 22:00 UTC.

Does this happen with any text in any buffer?  If the problem is
limited to some buffers, please try to figure out which buffers
exhibit the problem.

Also, please show the information collected by report-emacs-bug about
your build details.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51734; Package emacs. (Wed, 10 Nov 2021 14:09:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: yamaoka <at> jpl.org, 51734 <at> debbugs.gnu.org
Subject: Re: bug#51734: 29.0.50; got slow
Date: Wed, 10 Nov 2021 16:08:09 +0200
> Cc: 51734 <at> debbugs.gnu.org
> Date: Wed, 10 Nov 2021 20:38:32 +0800
> From:  Po Lu via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> > For instance, the cursor moves not smoothly while repeating `C-n's,
> > `C-s' takes a couple of seconds for the text searched to appear, etc.
> > It should have happened after my build on Thu 4 Nov 22:00 UTC
> > through the previous build on Mon 8 Nov 22:00 UTC.
> >
> > Thanks.
> 
> See below.
> 
> >  'configure 'CFLAGS=-O0 -g3' --verbose --with-x-toolkit=gtk3
> >  --with-imagemagick'
> 
> Did you notice the problem in the Emacs in which you ran
> `report-emacs-bug'?  `-O0 -g3' will normally slow down Emacs
> considerably, as it disables all compiler optimizations, and is used as
> a debugging aid.

Building Emacs with -O0 should never make Emacs so slow as described
by the OP.  Disabling optimizations generally makes Emacs about 2.5 to
3 times slower, but that's still a far cry from response time of a
second or two to C-s.

I use unoptimized builds of the development version all the time,
because optimized builds are very hard to debug.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51734; Package emacs. (Thu, 11 Nov 2021 02:44:02 GMT) Full text and rfc822 format available.

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

From: Katsumi Yamaoka <yamaoka <at> jpl.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51734 <at> debbugs.gnu.org
Subject: Re: bug#51734: 29.0.50; got slow
Date: Thu, 11 Nov 2021 11:43:36 +0900
[Message part 1 (text/plain, inline)]
On Wed, 10 Nov 2021 16:08:09 +0200, Eli Zaretskii wrote:
> Building Emacs with -O0 should never make Emacs so slow as described
> by the OP.  Disabling optimizations generally makes Emacs about 2.5 to
> 3 times slower, but that's still a far cry from response time of a
> second or two to C-s.

Yes, I have no problem with -O0 on Emacs master till last week
and also on 28, 27, 26.

On Wed, 10 Nov 2021 14:53:00 +0200, Eli Zaretskii wrote:
> Does this happen with any text in any buffer?  If the problem is
> limited to some buffers, please try to figure out which buffers
> exhibit the problem.

It happens on any buffer.

> Also, please show the information collected by report-emacs-bug about
> your build details.

What report-emacs-bug creates is attached below.  This was made
by Emacs from git head, built by `make bootstrap' a moment ago.

Probably what I should do could be bisecting the recent commits.

Thanks.

[Message part 2 (text/plain, inline)]
In GNU Emacs 29.0.50 (build 1, x86_64-pc-cygwin, GTK+ Version 3.22.28, cairo version 1.17.4)
 of 2021-11-11 built on ************
Windowing system distributor 'The Cygwin/X Project', version 11.0.12012000
Configured using:
 'configure 'CFLAGS=-O0 -g3' --verbose --with-x-toolkit=gtk3
 --with-imagemagick'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ
IMAGEMAGICK JPEG LCMS2 LIBOTF LIBXML2 M17N_FLT MODULES NOTIFY
GFILENOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS WEBP
X11 XDBE XIM XPM GTK3 ZLIB

Important settings:
  value of $LC_CTYPE: ja_JP.UTF-8
  value of $LC_MESSAGES: C
  value of $LANG: C
  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
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
/usr/local/share/emacs/29.0.50/site-lisp/flim/sasl hides /usr/local/share/emacs/29.0.50/lisp/net/sasl
/usr/local/share/emacs/29.0.50/site-lisp/egg/egg hides /usr/local/share/emacs/29.0.50/site-lisp/sj3-egg/egg

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media rmc puny
dired dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068
epg-config gnus-util rmail rmail-loaddefs auth-source cl-seq eieio
eieio-core cl-macs eieio-loaddefs password-cache json map
text-property-search seq gv byte-opt bytecomp byte-compile cconv
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils time-date subr-x help-mode cl-loaddefs cl-lib japan-util
iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd
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 cl-generic
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 simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads dbusbind
gfilenotify lcms2 dynamic-setting system-font-setting
font-render-setting cairo move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 16 57962 5923)
 (symbols 48 6803 1)
 (strings 32 19443 1699)
 (string-bytes 1 630570)
 (vectors 16 14836)
 (vector-slots 8 296901 9906)
 (floats 8 27 35)
 (intervals 56 202 0)
 (buffers 992 10))

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51734; Package emacs. (Thu, 11 Nov 2021 08:10:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Katsumi Yamaoka <yamaoka <at> jpl.org>
Cc: 51734 <at> debbugs.gnu.org
Subject: Re: bug#51734: 29.0.50; got slow
Date: Thu, 11 Nov 2021 10:09:30 +0200
> Date: Thu, 11 Nov 2021 11:43:36 +0900
> From: Katsumi Yamaoka <yamaoka <at> jpl.org>
> Cc: 51734 <at> debbugs.gnu.org
> 
> On Wed, 10 Nov 2021 16:08:09 +0200, Eli Zaretskii wrote:
> > Building Emacs with -O0 should never make Emacs so slow as described
> > by the OP.  Disabling optimizations generally makes Emacs about 2.5 to
> > 3 times slower, but that's still a far cry from response time of a
> > second or two to C-s.
> 
> Yes, I have no problem with -O0 on Emacs master till last week
> and also on 28, 27, 26.

Can you be more specific regarding which commit was the last one where
the problem didn't exist?

> Probably what I should do could be bisecting the recent commits.

That'd be best, if you can.  Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51734; Package emacs. (Thu, 11 Nov 2021 12:04:01 GMT) Full text and rfc822 format available.

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

From: Katsumi Yamaoka <yamaoka <at> jpl.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51734 <at> debbugs.gnu.org
Subject: Re: bug#51734: 29.0.50; got slow
Date: Thu, 11 Nov 2021 21:02:18 +0900
On Thu, 11 Nov 2021 10:09:30 +0200, Eli Zaretskii wrote:
>> Probably what I should do could be bisecting the recent commits.
> That'd be best, if you can.  Thanks.

I did it and found the revision that causes this problem on at
least Cygwin-64.  That is d5bb053.  However, as there are a lot
of changed files in a single commit, it seems hard to me to find
what change is the real cause.  I need a skillful Cygwin player.

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51734; Package emacs. (Thu, 11 Nov 2021 14:16:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Katsumi Yamaoka <yamaoka <at> jpl.org>
Cc: 51734 <at> debbugs.gnu.org
Subject: Re: bug#51734: 29.0.50; got slow
Date: Thu, 11 Nov 2021 16:15:50 +0200
> Date: Thu, 11 Nov 2021 21:02:18 +0900
> From: Katsumi Yamaoka <yamaoka <at> jpl.org>
> Cc: 51734 <at> debbugs.gnu.org
> 
> On Thu, 11 Nov 2021 10:09:30 +0200, Eli Zaretskii wrote:
> >> Probably what I should do could be bisecting the recent commits.
> > That'd be best, if you can.  Thanks.
> 
> I did it and found the revision that causes this problem on at
> least Cygwin-64.  That is d5bb053.  However, as there are a lot
> of changed files in a single commit, it seems hard to me to find
> what change is the real cause.  I need a skillful Cygwin player.

That's strange: that changeset changed just the docs, and the only
changes in code are in xwidget.c (which your build shouldn't compile)
and in keyboard.c, where the changes just remove redundant braces, and
again mostly in places that are built only when xwidgets are
supported.

If you revert only the changes in keyboard.c, does the problem go
away?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51734; Package emacs. (Thu, 11 Nov 2021 18:12:01 GMT) Full text and rfc822 format available.

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

From: Ken Brown <kbrown <at> cornell.edu>
To: Eli Zaretskii <eliz <at> gnu.org>, Katsumi Yamaoka <yamaoka <at> jpl.org>
Cc: 51734 <at> debbugs.gnu.org
Subject: Re: bug#51734: 29.0.50; got slow
Date: Thu, 11 Nov 2021 13:11:23 -0500
On 11/11/2021 9:15 AM, Eli Zaretskii wrote:
>> From: Katsumi Yamaoka <yamaoka <at> jpl.org>
>> On Thu, 11 Nov 2021 10:09:30 +0200, Eli Zaretskii wrote:
>>>> Probably what I should do could be bisecting the recent commits.
>>> That'd be best, if you can.  Thanks.
>>
>> I did it and found the revision that causes this problem on at
>> least Cygwin-64.  That is d5bb053.
>
> That's strange: that changeset changed just the docs, and the only
> changes in code are in xwidget.c (which your build shouldn't compile)
> and in keyboard.c, where the changes just remove redundant braces, and
> again mostly in places that are built only when xwidgets are
> supported.

I can confirm the extreme slowness on my 64-bit Cygwin system, but I don't agree 
with the bisection.  I still see the slowness in d5bb053^.

Ken




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51734; Package emacs. (Thu, 11 Nov 2021 18:35:01 GMT) Full text and rfc822 format available.

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

From: Ken Brown <kbrown <at> cornell.edu>
To: Eli Zaretskii <eliz <at> gnu.org>, Katsumi Yamaoka <yamaoka <at> jpl.org>
Cc: Lars Magne Ingebrigtsen <larsi <at> gnus.org>, 51734 <at> debbugs.gnu.org
Subject: Re: bug#51734: 29.0.50; got slow
Date: Thu, 11 Nov 2021 13:33:55 -0500
On 11/11/2021 1:11 PM, Ken Brown wrote:
> On 11/11/2021 9:15 AM, Eli Zaretskii wrote:
>>> From: Katsumi Yamaoka <yamaoka <at> jpl.org>
>>> On Thu, 11 Nov 2021 10:09:30 +0200, Eli Zaretskii wrote:
>>>>> Probably what I should do could be bisecting the recent commits.
>>>> That'd be best, if you can.  Thanks.
>>>
>>> I did it and found the revision that causes this problem on at
>>> least Cygwin-64.  That is d5bb053.
>>
>> That's strange: that changeset changed just the docs, and the only
>> changes in code are in xwidget.c (which your build shouldn't compile)
>> and in keyboard.c, where the changes just remove redundant braces, and
>> again mostly in places that are built only when xwidgets are
>> supported.
> 
> I can confirm the extreme slowness on my 64-bit Cygwin system, but I don't agree 
> with the bisection.  I still see the slowness in d5bb053^.

I just did my own bisection and found the following as the first bad commit:

commit 858868e36dbb8fe30fb5ae6a59ebb2fd123e307d
Author: Lars Ingebrigtsen <larsi <at> gnus.org>
Date:   Sun Nov 7 04:55:02 2021 +0100

    Actually start the alarms in atimer

    * src/atimer.c (set_alarm): Actually start both timerfd and
    alarms (attempted in 4107549a).

I haven't yet tried to figure out why.

Ken




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51734; Package emacs. (Thu, 11 Nov 2021 18:43:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: yamaoka <at> jpl.org, 51734 <at> debbugs.gnu.org
Subject: Re: bug#51734: 29.0.50; got slow
Date: Thu, 11 Nov 2021 20:42:08 +0200
> Date: Thu, 11 Nov 2021 13:11:23 -0500
> Cc: 51734 <at> debbugs.gnu.org
> From: Ken Brown <kbrown <at> cornell.edu>
> 
> >> I did it and found the revision that causes this problem on at
> >> least Cygwin-64.  That is d5bb053.
> >
> > That's strange: that changeset changed just the docs, and the only
> > changes in code are in xwidget.c (which your build shouldn't compile)
> > and in keyboard.c, where the changes just remove redundant braces, and
> > again mostly in places that are built only when xwidgets are
> > supported.
> 
> I can confirm the extreme slowness on my 64-bit Cygwin system, but I don't agree 
> with the bisection.  I still see the slowness in d5bb053^.

I'm relieved.

> I just did my own bisection and found the following as the first bad commit:
> 
> commit 858868e36dbb8fe30fb5ae6a59ebb2fd123e307d
> Author: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date:   Sun Nov 7 04:55:02 2021 +0100
> 
>      Actually start the alarms in atimer
> 
>      * src/atimer.c (set_alarm): Actually start both timerfd and
>      alarms (attempted in 4107549a).
> 
> I haven't yet tried to figure out why.

That makes much more sense, thanks.

Wasn't there some issue with SIGALRM and/or timerfd on Cygwin?  Or am
I dreaming?

If no better idea comes up, we could disable that change on Cygwin.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51734; Package emacs. (Thu, 11 Nov 2021 19:29:02 GMT) Full text and rfc822 format available.

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

From: Ken Brown <kbrown <at> cornell.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: yamaoka <at> jpl.org, 51734 <at> debbugs.gnu.org
Subject: Re: bug#51734: 29.0.50; got slow
Date: Thu, 11 Nov 2021 14:28:00 -0500
On 11/11/2021 1:42 PM, Eli Zaretskii wrote:
> That makes much more sense, thanks.
> 
> Wasn't there some issue with SIGALRM and/or timerfd on Cygwin?  Or am
> I dreaming?

You have a good memory!  There was an issue that timerfd was buggy when it was 
first introduced, but it was fixed not too much later.  See 
atimer.c:have_buggy_timerfd().

> If no better idea comes up, we could disable that change on Cygwin.

Sounds good.

Ken




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51734; Package emacs. (Thu, 11 Nov 2021 20:18:01 GMT) Full text and rfc822 format available.

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

From: Ken Brown <kbrown <at> cornell.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: yamaoka <at> jpl.org, 51734 <at> debbugs.gnu.org
Subject: Re: bug#51734: 29.0.50; got slow
Date: Thu, 11 Nov 2021 15:17:23 -0500
On 11/11/2021 2:28 PM, Ken Brown wrote:
> On 11/11/2021 1:42 PM, Eli Zaretskii wrote:
>> If no better idea comes up, we could disable that change on Cygwin.
> 
> Sounds good.

Here's a patch that does that.  Does it look OK?

Katsumi, can you verify that it fixes the problem for you?  If so, we can still 
wait a couple days to see if someone comes up with a better idea.

Ken




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51734; Package emacs. (Thu, 11 Nov 2021 20:21:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: yamaoka <at> jpl.org, 51734 <at> debbugs.gnu.org
Subject: Re: bug#51734: 29.0.50; got slow
Date: Thu, 11 Nov 2021 22:20:11 +0200
> Date: Thu, 11 Nov 2021 15:17:23 -0500
> From: Ken Brown <kbrown <at> cornell.edu>
> Cc: yamaoka <at> jpl.org, 51734 <at> debbugs.gnu.org
> 
> On 11/11/2021 2:28 PM, Ken Brown wrote:
> > On 11/11/2021 1:42 PM, Eli Zaretskii wrote:
> >> If no better idea comes up, we could disable that change on Cygwin.
> > 
> > Sounds good.
> 
> Here's a patch that does that.  Does it look OK?

ENOPATCH




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51734; Package emacs. (Thu, 11 Nov 2021 20:32:01 GMT) Full text and rfc822 format available.

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

From: Ken Brown <kbrown <at> cornell.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: yamaoka <at> jpl.org, 51734 <at> debbugs.gnu.org
Subject: Re: bug#51734: 29.0.50; got slow
Date: Thu, 11 Nov 2021 15:30:51 -0500
[Message part 1 (text/plain, inline)]
On 11/11/2021 3:20 PM, Eli Zaretskii wrote:
>> Date: Thu, 11 Nov 2021 15:17:23 -0500
>> From: Ken Brown <kbrown <at> cornell.edu>
>> Cc: yamaoka <at> jpl.org, 51734 <at> debbugs.gnu.org
>>
>> On 11/11/2021 2:28 PM, Ken Brown wrote:
>>> On 11/11/2021 1:42 PM, Eli Zaretskii wrote:
>>>> If no better idea comes up, we could disable that change on Cygwin.
>>>
>>> Sounds good.
>>
>> Here's a patch that does that.  Does it look OK?
> 
> ENOPATCH

Sorry.
[0001-Don-t-start-both-timerfd-and-alarms-on-Cygwin.patch (text/plain, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51734; Package emacs. (Thu, 11 Nov 2021 20:37:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: yamaoka <at> jpl.org, 51734 <at> debbugs.gnu.org
Subject: Re: bug#51734: 29.0.50; got slow
Date: Thu, 11 Nov 2021 22:36:33 +0200
> Date: Thu, 11 Nov 2021 15:30:51 -0500
> Cc: yamaoka <at> jpl.org, 51734 <at> debbugs.gnu.org
> From: Ken Brown <kbrown <at> cornell.edu>
> 
> >> Here's a patch that does that.  Does it look OK?
> > 
> > ENOPATCH
> 
> Sorry.
> 
> From abe88311b7e47c1cdac2b2405d43ff19826fd911 Mon Sep 17 00:00:00 2001
> From: Ken Brown <kbrown <at> cornell.edu>
> Date: Thu, 11 Nov 2021 15:09:24 -0500
> Subject: [PATCH] Don't start both timerfd and alarms on Cygwin
> 
> * src/atimer.c (set_alarm) [CYGWIN]: Don't start both timerfd and
> alarms; this causes a slowdown.  (Bug#51734)
> ---
>  src/atimer.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/src/atimer.c b/src/atimer.c
> index 490c21bff1..9bde9c2446 100644
> --- a/src/atimer.c
> +++ b/src/atimer.c
> @@ -316,6 +316,13 @@ set_alarm (void)
>  	      exit = true;
>  	    }
>  # endif
> +
> +# ifdef CYGWIN
> +	  /* Don't start both timerfd and alarms on Cygwin; this
> +	     causes a slowdown (bug#51734). */
> +	  if (exit)
> +	    return;
> +# endif
>  	  if (alarm_timer_ok
>  	      && timer_settime (alarm_timer, TIMER_ABSTIME, &ispec, 0) == 0)
>  	    exit = true;
> -- 

LGTM, thanks.  It would be good to understand why starting alarms
causes slowdown on Cygwin, though.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51734; Package emacs. (Thu, 11 Nov 2021 23:46:02 GMT) Full text and rfc822 format available.

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

From: Katsumi Yamaoka <yamaoka <at> jpl.org>
To: Eli Zaretskii <eliz <at> gnu.org>, Ken Brown <kbrown <at> cornell.edu>
Cc: 51734 <at> debbugs.gnu.org
Subject: Re: bug#51734: 29.0.50; got slow
Date: Fri, 12 Nov 2021 08:45:42 +0900
On Thu, 11 Nov 2021 15:30:51 -0500, Ken Brown wrote:
>> * src/atimer.c (set_alarm) [CYGWIN]: Don't start both timerfd and
>> alarms; this causes a slowdown.  (Bug#51734)

I verified this patch makes Emacs HEAD normal on Cygwin-64.
Thanks a lot!

On Thu, 11 Nov 2021 16:15:50 +0200, Eli Zaretskii wrote:
>> I did it and found the revision that causes this problem on at
>> least Cygwin-64.  That is d5bb053.  However,

> That's strange: that changeset changed just the docs, and the only
> changes in code are in xwidget.c (which your build shouldn't compile)
> and...

I seem to have tested Emacs too hastily or too much expectedly,
sorry.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51734; Package emacs. (Fri, 12 Nov 2021 18:23:02 GMT) Full text and rfc822 format available.

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

From: Ken Brown <kbrown <at> cornell.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: yamaoka <at> jpl.org, 51734 <at> debbugs.gnu.org
Subject: Re: bug#51734: 29.0.50; got slow
Date: Fri, 12 Nov 2021 13:22:28 -0500
On 11/11/2021 3:36 PM, Eli Zaretskii wrote:
> LGTM, thanks.  It would be good to understand why starting alarms
> causes slowdown on Cygwin, though.

I asked on the cygwin-developers list, and Corinna is not aware of any reason 
there should be a problem using timerfd and POSIX timers simultaneously.  [In 
case it wasn't clear, the slowdown occurs only if we use both timerfd and 
alarms; either one by itself is fine.]

The only thing I can think of is that Cygwin is probably the only system that 
has timerfd and that also has to use timers to poll for input.  (The others all 
use SIGIO, if I'm not mistaken.)  By using two different kinds of timers 
simultaneously, we're getting timers expiring twice as often and not at regular 
intervals.  Could this account for the slowdown?

In any case, I think I should go ahead and install the patch to make the master 
branch usable again on Cygwin.

Ken




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51734; Package emacs. (Fri, 12 Nov 2021 19:27:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: yamaoka <at> jpl.org, 51734 <at> debbugs.gnu.org
Subject: Re: bug#51734: 29.0.50; got slow
Date: Fri, 12 Nov 2021 21:26:32 +0200
> Date: Fri, 12 Nov 2021 13:22:28 -0500
> Cc: yamaoka <at> jpl.org, 51734 <at> debbugs.gnu.org
> From: Ken Brown <kbrown <at> cornell.edu>
> 
> The only thing I can think of is that Cygwin is probably the only system that 
> has timerfd and that also has to use timers to poll for input.  (The others all 
> use SIGIO, if I'm not mistaken.)  By using two different kinds of timers 
> simultaneously, we're getting timers expiring twice as often and not at regular 
> intervals.  Could this account for the slowdown?

At what frequency does the other timer tick, the one used to poll for
input?

> In any case, I think I should go ahead and install the patch to make the master 
> branch usable again on Cygwin.

Feel free.




Reply sent to Ken Brown <kbrown <at> cornell.edu>:
You have taken responsibility. (Fri, 12 Nov 2021 20:07:01 GMT) Full text and rfc822 format available.

Notification sent to Katsumi Yamaoka <yamaoka <at> jpl.org>:
bug acknowledged by developer. (Fri, 12 Nov 2021 20:07:02 GMT) Full text and rfc822 format available.

Message #64 received at 51734-done <at> debbugs.gnu.org (full text, mbox):

From: Ken Brown <kbrown <at> cornell.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51734-done <at> debbugs.gnu.org, yamaoka <at> jpl.org
Subject: Re: bug#51734: 29.0.50; got slow
Date: Fri, 12 Nov 2021 15:06:33 -0500
On 11/12/2021 2:26 PM, Eli Zaretskii wrote:
>> Date: Fri, 12 Nov 2021 13:22:28 -0500
>> Cc: yamaoka <at> jpl.org, 51734 <at> debbugs.gnu.org
>> From: Ken Brown <kbrown <at> cornell.edu>
>>
>> The only thing I can think of is that Cygwin is probably the only system that
>> has timerfd and that also has to use timers to poll for input.  (The others all
>> use SIGIO, if I'm not mistaken.)  By using two different kinds of timers
>> simultaneously, we're getting timers expiring twice as often and not at regular
>> intervals.  Could this account for the slowdown?
> 
> At what frequency does the other timer tick, the one used to poll for
> input?

They're both used to poll for input, and both at the same frequency (I think 
every second).  For systems without SIGIO, keyboard.c:start_polling creates an 
atimer "poll_timer" via a call to start_atimer.  The latter calls set_alarm, 
which now (after commit 858868e3) calls both timerfd_settime and timer_settime. 
 So we have both a timerfd and a POSIX timer, both serving the same purpose AFAICT.

When I said "not at regular intervals" above, I meant that there will sometimes 
be delays before Emacs notices a timer expiring, so the two timers will get out 
of phase with another.

I hope this makes some sense.  I find keyboard.c and the whole alarm setup 
confusing, so I could easily have gotten some things wrong.

>> In any case, I think I should go ahead and install the patch to make the master
>> branch usable again on Cygwin.
> 
> Feel free.

Done, and I'm closing the bug.

Ken




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51734; Package emacs. (Sun, 14 Nov 2021 01:15:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: 51734 <at> debbugs.gnu.org
Cc: yamaoka <at> jpl.org, kbrown <at> cornell.edu
Subject: Re: bug#51734: 29.0.50; got slow
Date: Sun, 14 Nov 2021 02:13:47 +0100
Ken Brown <kbrown <at> cornell.edu> writes:

> They're both used to poll for input, and both at the same frequency (I
> think every second).  For systems without SIGIO,
> keyboard.c:start_polling creates an atimer "poll_timer" via a call to
> start_atimer.  The latter calls set_alarm, which now (after commit
> 858868e3) calls both timerfd_settime and timer_settime.   So we have
> both a timerfd and a POSIX timer, both serving the same purpose
> AFAICT.

Would disabling timerfd (instead of disabling the POSIX timer) also fix
the issue?  If so, I'd rather do that, because the timerfd timers aren't
delivered while Emacs is busy, which makes things like the hourglass
pointer not be displayed reliably.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51734; Package emacs. (Sun, 14 Nov 2021 15:43:02 GMT) Full text and rfc822 format available.

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

From: Ken Brown <kbrown <at> cornell.edu>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, 51734 <at> debbugs.gnu.org
Cc: yamaoka <at> jpl.org
Subject: Re: bug#51734: 29.0.50; got slow
Date: Sun, 14 Nov 2021 10:42:14 -0500
[Message part 1 (text/plain, inline)]
On 11/13/2021 8:13 PM, Lars Ingebrigtsen wrote:
> Would disabling timerfd (instead of disabling the POSIX timer) also fix
> the issue?

Yes.

> If so, I'd rather do that, because the timerfd timers aren't
> delivered while Emacs is busy, which makes things like the hourglass
> pointer not be displayed reliably.

How's the attached patch?

Ken
[0001-Prefer-POSIX-timers-to-timerfd-timers.patch (text/plain, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51734; Package emacs. (Sun, 14 Nov 2021 18:00:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: yamaoka <at> jpl.org, 51734 <at> debbugs.gnu.org
Subject: Re: bug#51734: 29.0.50; got slow
Date: Sun, 14 Nov 2021 18:58:56 +0100
Ken Brown <kbrown <at> cornell.edu> writes:

> How's the attached patch?

[...]

> * src/atimer.c (set_alarm): Try to start a POSIX timer before
> starting a timerfd timer.  On Cygwin, return if the POSIX timer is
> started successfully. (Bug#51734)

Looks good to me.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51734; Package emacs. (Sun, 14 Nov 2021 19:12:01 GMT) Full text and rfc822 format available.

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

From: Ken Brown <kbrown <at> cornell.edu>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: yamaoka <at> jpl.org, 51734 <at> debbugs.gnu.org
Subject: Re: bug#51734: 29.0.50; got slow
Date: Sun, 14 Nov 2021 14:11:25 -0500
On 11/14/2021 12:58 PM, Lars Ingebrigtsen wrote:
> Looks good to me.

Pushed.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Mon, 13 Dec 2021 12:24:09 GMT) Full text and rfc822 format available.

This bug report was last modified 2 years and 96 days ago.

Previous Next


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