GNU bug report logs - #51734
29.0.50; got slow

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Katsumi Yamaoka <yamaoka <at> jpl.org>
Subject: bug#51734: closed (Re: bug#51734: 29.0.50; got slow)
Date: Fri, 12 Nov 2021 20:07:02 +0000

[Message part 1 (text/plain, inline)]

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 51734 <at> debbugs.gnu.org.

-- 
51734: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=51734
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

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

[Message part 3 (message/rfc822, inline)]

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'

Previous Next

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