bug#51734: 29.0.50; got slow

bug#51734: 29.0.50; got slow

[Katsumi Yamaoka]

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'

bug#51734: 29.0.50; got slow

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Katsumi Yamaoka <yamaoka@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.

bug#51734: 29.0.50; got slow

[Eli Zaretskii]

> Date: Wed, 10 Nov 2021 09:36:14 +0900
> From: Katsumi Yamaoka <yamaoka@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.

bug#51734: 29.0.50; got slow

[Eli Zaretskii]

> Cc: 51734@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@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.

bug#51734: 29.0.50; got slow

[Katsumi Yamaoka]

[-- Attachment #1: Type: text/plain, Size: 923 bytes --]

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.


[-- Attachment #2: Type: text/plain, Size: 3203 bytes --]

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))

bug#51734: 29.0.50; got slow

[Eli Zaretskii]

> Date: Thu, 11 Nov 2021 11:43:36 +0900
> From: Katsumi Yamaoka <yamaoka@jpl.org>
> Cc: 51734@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.

bug#51734: 29.0.50; got slow

[Katsumi Yamaoka]

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.

bug#51734: 29.0.50; got slow

[Eli Zaretskii]

> Date: Thu, 11 Nov 2021 21:02:18 +0900
> From: Katsumi Yamaoka <yamaoka@jpl.org>
> Cc: 51734@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?

bug#51734: 29.0.50; got slow

[Ken Brown]

On 11/11/2021 9:15 AM, Eli Zaretskii wrote:
>> From: Katsumi Yamaoka <yamaoka@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

bug#51734: 29.0.50; got slow

[Ken Brown]

On 11/11/2021 1:11 PM, Ken Brown wrote:
> On 11/11/2021 9:15 AM, Eli Zaretskii wrote:
>>> From: Katsumi Yamaoka <yamaoka@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@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

bug#51734: 29.0.50; got slow

[Eli Zaretskii]

> Date: Thu, 11 Nov 2021 13:11:23 -0500
> Cc: 51734@debbugs.gnu.org
> From: Ken Brown <kbrown@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@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.

bug#51734: 29.0.50; got slow

[Ken Brown]

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

bug#51734: 29.0.50; got slow

[Ken Brown]

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

bug#51734: 29.0.50; got slow

[Eli Zaretskii]

> Date: Thu, 11 Nov 2021 15:17:23 -0500
> From: Ken Brown <kbrown@cornell.edu>
> Cc: yamaoka@jpl.org, 51734@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

bug#51734: 29.0.50; got slow

[Ken Brown]

[-- Attachment #1: Type: text/plain, Size: 435 bytes --]

On 11/11/2021 3:20 PM, Eli Zaretskii wrote:
>> Date: Thu, 11 Nov 2021 15:17:23 -0500
>> From: Ken Brown <kbrown@cornell.edu>
>> Cc: yamaoka@jpl.org, 51734@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.

[-- Attachment #2: 0001-Don-t-start-both-timerfd-and-alarms-on-Cygwin.patch --]
[-- Type: text/plain, Size: 856 bytes --]

From abe88311b7e47c1cdac2b2405d43ff19826fd911 Mon Sep 17 00:00:00 2001
From: Ken Brown <kbrown@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;
-- 
2.33.0

bug#51734: 29.0.50; got slow

[Eli Zaretskii]

> Date: Thu, 11 Nov 2021 15:30:51 -0500
> Cc: yamaoka@jpl.org, 51734@debbugs.gnu.org
> From: Ken Brown <kbrown@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@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.

bug#51734: 29.0.50; got slow

[Katsumi Yamaoka]

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.

bug#51734: 29.0.50; got slow

[Ken Brown]

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

bug#51734: 29.0.50; got slow

[Eli Zaretskii]

> Date: Fri, 12 Nov 2021 13:22:28 -0500
> Cc: yamaoka@jpl.org, 51734@debbugs.gnu.org
> From: Ken Brown <kbrown@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.

bug#51734: 29.0.50; got slow

[Ken Brown]

On 11/12/2021 2:26 PM, Eli Zaretskii wrote:
>> Date: Fri, 12 Nov 2021 13:22:28 -0500
>> Cc: yamaoka@jpl.org, 51734@debbugs.gnu.org
>> From: Ken Brown <kbrown@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

bug#51734: 29.0.50; got slow

[Lars Ingebrigtsen]

Ken Brown <kbrown@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

bug#51734: 29.0.50; got slow

[Ken Brown]

[-- Attachment #1: Type: text/plain, Size: 344 bytes --]

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

[-- Attachment #2: 0001-Prefer-POSIX-timers-to-timerfd-timers.patch --]
[-- Type: text/plain, Size: 1828 bytes --]

From 1aee29152833e7a121b629021f975423570ad2d2 Mon Sep 17 00:00:00 2001
From: Ken Brown <kbrown@cornell.edu>
Date: Sun, 14 Nov 2021 10:30:44 -0500
Subject: [PATCH] Prefer POSIX timers to timerfd timers

* 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)
---
 src/atimer.c | 27 ++++++++++++++++-----------
 1 file changed, 16 insertions(+), 11 deletions(-)

diff --git a/src/atimer.c b/src/atimer.c
index 9bde9c2446..df35603f32 100644
--- a/src/atimer.c
+++ b/src/atimer.c
@@ -309,24 +309,29 @@ set_alarm (void)
 	  struct itimerspec ispec;
 	  ispec.it_value = atimers->expiration;
 	  ispec.it_interval.tv_sec = ispec.it_interval.tv_nsec = 0;
+	  if (alarm_timer_ok
+	      && timer_settime (alarm_timer, TIMER_ABSTIME, &ispec, 0) == 0)
+	    exit = true;
+
+	  /* Don't start both timerfd and POSIX timers on Cygwin; this
+	     causes a slowdown (bug#51734).  Prefer POSIX timers
+	     because the timerfd notifications aren't delivered while
+	     Emacs is busy, which prevents things like the hourglass
+	     pointer from being displayed reliably (bug#19776). */
+# ifdef CYGWIN
+	  if (exit)
+	    return;
+# endif
+
 # ifdef HAVE_TIMERFD
-	  if (timerfd_settime (timerfd, TFD_TIMER_ABSTIME, &ispec, 0) == 0)
+	  if (0 <= timerfd
+	      && timerfd_settime (timerfd, TFD_TIMER_ABSTIME, &ispec, 0) == 0)
 	    {
 	      add_timer_wait_descriptor (timerfd);
 	      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;
-
 	  if (exit)
 	    return;
 	}
-- 
2.33.0

bug#51734: 29.0.50; got slow

[Lars Ingebrigtsen]

Ken Brown <kbrown@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

bug#51734: 29.0.50; got slow

[Ken Brown]

On 11/14/2021 12:58 PM, Lars Ingebrigtsen wrote:
> Looks good to me.

Pushed.