bug#21597: 25.0.50; Extremely slow redisplay on emacsclient

bug#21597: 25.0.50; Extremely slow redisplay on emacsclient

[Kaushal Modi]

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

Hi,

BUG: All basic operations like navigation (C-p, C-n,..), typing in the
minibuffer, etc are extremely sluggish.. latency in the order of 10s of
seconds!

I am seeing this bug since the emacs built from master yesterday and even
in the latest build as of writing this email.

The bug is not seen when running emacs -Q&.

But it is seen if try to get "emacs -Q" behaviour in emacsclient.

So I moved my actual init.el to a temp file and add just the below code in
the init.el

(require 'server)
(if (not (server-running-p))
    (server-start))

- After that, start "emacsclient -a '' -c &". The *scratch* buffer should
open in a frame.
- Now when you do something simple like C-p, you won't see the cursor move
at all. But as soon as you try to type something, it will get typed on the
above line, that too with a huge latency between the moment you hit a
character and that char showing up in the *scratch* buffer.

I believe this to have been caused by this commit:
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=5c9304ea86b8cfc9d0b6d7769b90bd56e5dd1313


In GNU Emacs 25.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.23)
 of 2015-10-01
Repository revision: 9c86325b69d75e9b17ff468f5a2220597979635f
Windowing system distributor 'The X.Org Foundation', version 11.0.60900000
System Description: Red Hat Enterprise Linux Workstation release 6.6
(Santiago)

Configured using:
 'configure --prefix=/home/kmodi/usr_local/apps/6/emacs/master
 'CPPFLAGS=-fgnu89-inline -I/home/kmodi/usr_local/6/include
 -I/usr/include/freetype2 -I/usr/include'
 'LDFLAGS=-L/home/kmodi/usr_local/6/lib
 -L/home/kmodi/usr_local/6/lib64''

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK2 X11

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=none
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message dired format-spec
rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util help-fns help-mode easymenu cl-loaddefs pcase cl-lib mail-prsvr
mail-utils server time-date mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
frame 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 charscript
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote dbusbind inotify
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 80898 8068)
 (symbols 48 19419 0)
 (miscs 40 74 110)
 (strings 32 13203 5056)
 (string-bytes 1 399479)
 (vectors 16 10847)
 (vector-slots 8 417204 6305)
 (floats 8 133 42)
 (intervals 56 222 0)
 (buffers 976 13)
 (heap 1024 27076 657))



--
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 13274 bytes --]

bug#21597: 25.0.50; Extremely slow redisplay on emacsclient

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Thu, 1 Oct 2015 10:26:31 -0400
> 
> BUG: All basic operations like navigation (C-p, C-n,..), typing in the
> minibuffer, etc are extremely sluggish.. latency in the order of 10s of
> seconds!
> 
> I am seeing this bug since the emacs built from master yesterday and even in
> the latest build as of writing this email.
> 
> The bug is not seen when running emacs -Q&.
> 
> But it is seen if try to get "emacs -Q" behaviour in emacsclient.
> 
> So I moved my actual init.el to a temp file and add just the below code in the
> init.el
> 
> (require 'server)
> (if (not (server-running-p))
> (server-start))
> 
> - After that, start "emacsclient -a '' -c &". The *scratch* buffer should open
> in a frame. 
> - Now when you do something simple like C-p, you won't see the cursor move at
> all. But as soon as you try to type something, it will get typed on the above
> line, that too with a huge latency between the moment you hit a character and
> that char showing up in the *scratch* buffer.

Very strange.  I don't see anything like that here.  Did you run
emacsclient on the same machine where the Emacs server runs, or over a
network?

> I believe this to have been caused by this commit:
> http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=5c9304ea86b8cfc9d0b6d7769b90bd56e5dd1313

If you revert the changes in that commit, does the problem go away?
(Please disregard the changes in gdb-mi.el, they are unrelated.)  If
it does, can you try reverting each hunk separately, and tell which
one has the most effect?

Thanks.

bug#21597: 25.0.50; Extremely slow redisplay on emacsclient

[Kaushal Modi]

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

Hi Eli,

I reverted to one prior commit (
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=82df1878e6559188e688195f992fff10f35035e8
) and the issue is gone.

> Did you run emacsclient on the same machine where the Emacs server runs?

I do not start an "emacs --daemon" server. I have (server-start) in my
init.el. (At some point in my prior builds, emacs --daemon never worked for
me.)
So my very first launch of emacs is always "emacsclient -a '' -c" to get an
emacs frame.
Every other launch is "emacsclient -a''" to open files from the terminal in
the same frame.
All of this is always on the same $HOST.

> can you try reverting each hunk separately

Do you mean reverting each of those hunks within xdisp.c? Or revert just
the xdisp.c hunk?
Building emacs takes quite some time on my machine.. so my turnaround time
will be really slow.


--
Kaushal Modi

On Thu, Oct 1, 2015 at 12:15 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Kaushal Modi <kaushal.modi@gmail.com>
> > Date: Thu, 1 Oct 2015 10:26:31 -0400
> >
> > BUG: All basic operations like navigation (C-p, C-n,..), typing in the
> > minibuffer, etc are extremely sluggish.. latency in the order of 10s of
> > seconds!
> >
> > I am seeing this bug since the emacs built from master yesterday and
> even in
> > the latest build as of writing this email.
> >
> > The bug is not seen when running emacs -Q&.
> >
> > But it is seen if try to get "emacs -Q" behaviour in emacsclient.
> >
> > So I moved my actual init.el to a temp file and add just the below code
> in the
> > init.el
> >
> > (require 'server)
> > (if (not (server-running-p))
> > (server-start))
> >
> > - After that, start "emacsclient -a '' -c &". The *scratch* buffer
> should open
> > in a frame.
> > - Now when you do something simple like C-p, you won't see the cursor
> move at
> > all. But as soon as you try to type something, it will get typed on the
> above
> > line, that too with a huge latency between the moment you hit a
> character and
> > that char showing up in the *scratch* buffer.
>
> Very strange.  I don't see anything like that here.  Did you run
> emacsclient on the same machine where the Emacs server runs, or over a
> network?
>
> > I believe this to have been caused by this commit:
> >
> http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=5c9304ea86b8cfc9d0b6d7769b90bd56e5dd1313
>
> If you revert the changes in that commit, does the problem go away?
> (Please disregard the changes in gdb-mi.el, they are unrelated.)  If
> it does, can you try reverting each hunk separately, and tell which
> one has the most effect?
>
> Thanks.
>

[-- Attachment #2: Type: text/html, Size: 5559 bytes --]

bug#21597: 25.0.50; Extremely slow redisplay on emacsclient

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Thu, 1 Oct 2015 12:30:11 -0400
> Cc: "bug-gnu-emacs@gnu.org" <bug-gnu-emacs@gnu.org>
> 
> I reverted to one prior commit (
> http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=82df1878e6559188e688195f992fff10f35035e8 )
> and the issue is gone.

Please try the latest master.

bug#21597: 25.0.50; Extremely slow redisplay on emacsclient

[Andrew Cohen]

I have experienced more or less the same bug. I see the described
behavior when starting emacs in daemon mode (emacs --daemon) and then
connecting with emacsclient. If I start emacs normally, execute
`server-start` , and then connect with emacsclient the problem with
redisplay does not occur.


Following the suggestion to test each hunk in the commit

http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=5c9304ea86b8cfc9d0b6d7769b90bd56e5dd1313

I tried reverting hunks one at a time. The only one that made a
difference was this one:


-  if (consider_all_windows_p)
+  if (!consider_all_windows_p)
     {
       FOR_EACH_FRAME (tail, frame)
-	XFRAME (frame)->updated_p = false;
+	{
+	  if (XFRAME (frame)->redisplay && XFRAME (frame) != sf)
+	    {
+	      consider_some_frames_p = true;
+	      break;
+	    }
+	}
+    }
+
+  if (consider_all_windows_p || consider_some_frames_p)
+    {
+      FOR_EACH_FRAME (tail, frame)
+	{
+	  if (XFRAME (frame)->redisplay || consider_all_windows_p)
+	    XFRAME (frame)->updated_p = false;
+	}

Reverting this solved the problem for me.

bug#21597: fixed

[Andrew Cohen]

Sorry, my report crossed the fix. Problem is resolved for me in latest
master. 

bug#21597: 25.0.50; Extremely slow redisplay on emacsclient

[Kaushal Modi]

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

This commit did not fix the problem (
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=c4c1fb97727ff52bcfa83ad5ed94a64a93d12e59
).
Rebuilding with this commit now (
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=511a18ded332917b2df698be4d2c357eb2f270fd
) .. Will update you once done.



--
Kaushal Modi

On Thu, Oct 1, 2015 at 12:59 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Kaushal Modi <kaushal.modi@gmail.com>
> > Date: Thu, 1 Oct 2015 12:30:11 -0400
> > Cc: "bug-gnu-emacs@gnu.org" <bug-gnu-emacs@gnu.org>
> >
> > I reverted to one prior commit (
> >
> http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=82df1878e6559188e688195f992fff10f35035e8
> )
> > and the issue is gone.
>
> Please try the latest master.
>

[-- Attachment #2: Type: text/html, Size: 2041 bytes --]

bug#21597: 25.0.50; Extremely slow redisplay on emacsclient

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Thu, 1 Oct 2015 13:39:39 -0400
> Cc: "bug-gnu-emacs@gnu.org" <bug-gnu-emacs@gnu.org>, 21597-done@debbugs.gnu.org
> 
> The 511a18 build fixed it! Thank you.

Great, thanks.

> btw were you able to reproduce the bug?

Eventually, yes.  I initially misunderstood your report as saying that
the problem was explicitly NOT with the daemon mode, so I tried
emacsclient against a server that ran in a "normal" session.  But the
problem was specifically with a situation where there is at least one
daemon frame.

bug#21597: 25.0.50; Extremely slow redisplay on emacsclient

[Kaushal Modi]

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

Just FYI, the fix in 511a18 commit is still good after the earlier trial
fix reversal commit (
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=6083f333ed38aa65f1d0a4c2bd7505a29e887444
).


--
Kaushal Modi

On Thu, Oct 1, 2015 at 1:54 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Kaushal Modi <kaushal.modi@gmail.com>
> > Date: Thu, 1 Oct 2015 13:39:39 -0400
> > Cc: "bug-gnu-emacs@gnu.org" <bug-gnu-emacs@gnu.org>,
> 21597-done@debbugs.gnu.org
> >
> > The 511a18 build fixed it! Thank you.
>
> Great, thanks.
>
> > btw were you able to reproduce the bug?
>
> Eventually, yes.  I initially misunderstood your report as saying that
> the problem was explicitly NOT with the daemon mode, so I tried
> emacsclient against a server that ran in a "normal" session.  But the
> problem was specifically with a situation where there is at least one
> daemon frame.
>

[-- Attachment #2: Type: text/html, Size: 1811 bytes --]

bug#21597: 25.0.50; Extremely slow redisplay on emacsclient

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Thu, 1 Oct 2015 14:55:22 -0400
> Cc: 21597@debbugs.gnu.org
> 
> Just FYI, the fix in 511a18 commit is still good after the earlier trial fix
> reversal commit (
> http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=6083f333ed38aa65f1d0a4c2bd7505a29e887444 ).
> 

Thanks.