Subject: bug#51734: closed (Re: bug#51734: 29.0.50; got slow)

From: [email-masked] (GNU bug Tracking System)
Date: Fri, 12 Nov 2021 20:07:02 +0000

Your bug report

#51734: 29.0.50; got slow

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
51734: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=51734
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#51734: 29.0.50; got slow
From: Ken Brown <[email-masked]>
To: Eli Zaretskii <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Fri, 12 Nov 2021 15:06:33 -0500
List-Id: <debbugs-submit.debbugs.gnu.org>

On 11/12/2021 2:26 PM, Eli Zaretskii wrote:
>> Date: Fri, 12 Nov 2021 13:22:28 -0500
>> Cc: [email-masked], [email-masked]
>> From: Ken Brown <[email-masked]>
>>
>> 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

Subject: 29.0.50; got slow
From: Katsumi Yamaoka <[email-masked]>
To: [email-masked]
Date: Wed, 10 Nov 2021 09:36:14 +0900
List-Id: <debbugs-submit.debbugs.gnu.org>

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'