Re: Excessive redisplay from lots of process output

[Po Lu <luangruo@yahoo.com>]

Eli Zaretskii <eliz@gnu.org> writes:

> The backtrace posted by Spencer tells us that Emacs called
> redisplay_preserve_echo_area:
>
>>#0  0x00007ffff4abc5c0 in XFlush () at /lib64/libX11.so.6
>>#1  0x00000000004d23d6 in x_flush (f=<optimized out>) at xterm.c:250
>>#2  0x00000000004d2416 in x_flip_and_flush (f=0xf956d0) at xterm.c:246
>>#3  0x00000000004d2416 in x_flip_and_flush (f=0xf956d0) at xterm.c:1230
>>#4  0x0000000000461374 in redisplay_preserve_echo_area (f=<optimized
>>out>) at frame.h:1700
>>#5  0x0000000000461374 in redisplay_preserve_echo_area
>>(from_where=from_where@entry=12) at xdisp.c:16527
>>#6  0x00000000005bee33 in wait_reading_process_output
>>(time_limit=time_limit@entry=0, nsecs=nsecs@entry=0,
>>read_kbd=read_kbd@entry=-1, do_display=true,
>>wait_for_cell=wait_for_cell@entry=0x0, wait_proc=wait_proc@entry=0x0,
>>just_wait_proc=just_wait_proc@entry=0) at process.c:5808
>>#7  0x000000000050aea4 in read_char (end_time=0x0,
>>used_mouse_menu=0x7fffffffda5b, kbp=<synthetic pointer>) at
>>keyboard.c:3926
>
> And redisplay_preserve_echo_area calls flush_frame unconditionally for
> the selected frame:
>
>   void
>   redisplay_preserve_echo_area (int from_where)
>   {
>     redisplay_trace ("redisplay_preserve_echo_area (%d)\n", from_where);
>
>     block_input ();
>     specpdl_ref count = SPECPDL_INDEX ();
>     record_unwind_protect_void (unwind_redisplay_preserve_echo_area);
>     block_buffer_flips ();
>     unblock_input ();
>
>     if (!NILP (echo_area_buffer[1]))
>       {
> 	/* We have a previously displayed message, but no current
> 	   message.  Redisplay the previous message.  */
> 	display_last_displayed_message_p = true;
> 	redisplay_internal ();
> 	display_last_displayed_message_p = false;
>       }
>     else
>       redisplay_internal ();
>
>     flush_frame (SELECTED_FRAME ());  <<<<<<<<<<<<<<<<<<<<<<<<<<<<
>     unbind_to (count, Qnil);
>   }
>
> How can we avoid this call to flush_frame "when nothing on the display
> has actually changed"?  We don't have any mechanism for update_frame
> and/or redisplay_internal to tell back whether anything was changed on
> display.  There's a lot that _can_ change:

XFlush (called by flush_frame) is the function which avoids doing
anything if nothing on the display has changed, as it makes no requests
itself.  Calling flush_frame after a redisplay which does nothing is
harmless; all the OP is experiencing tells us is that XFlush is not to
blame, but most likely some other X protocol request calling _XReply.

> Where do we call _XReply and for what purpose?  I don't see it in our
> sources anywhere.

_XReply is the function called with Xlib whenever you make an X protocol
request that has a reply, such as XGetWindowProperty:

  dpyinfo = FRAME_DISPLAY_INFO (f);

  if (XGetWindowProperty (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f),
			  dpyinfo->Xatom_wm_state, 0, 2, False,
			  AnyPropertyType, &type, &format, &nitems,
			  &bytes_after, &data) != Success)
    return;

  if (!data || nitems != 2 || format != 32)
    {

This is expensive because it involves sending a request to the X server
and waiting for a response, which easily takes hundereds of ms over a
slow network connection.

Fortunately, Emacs 29 should not call XSync as much as Emacs 28 did.
Which is why I asked Spencer to try it out.