unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Po Lu <Luangruo@yahoo.com>
To: emacs-devel@gnu.org, Eli Zaretskii <eliz@gnu.org>,
	Spencer Baugh <sbaugh@janestreet.com>
Cc: azeng@janestreet.com
Subject: Re: Excessive redisplay from lots of process output
Date: Sat, 25 Feb 2023 07:14:30 +0800	[thread overview]
Message-ID: <5BF9DB30-1CC1-450D-BCAE-A979B06DDE6B@yahoo.com> (raw)
In-Reply-To: <834jran5x4.fsf@gnu.org>

XFlush is not so expensive, as it simply makes requests that are already in the output buffer happen.  An implicit flush happens before XNextEvent, XEventsQueued, and XPending.

What is expensive is _XReply, so I would guess that is the source or Spencer's problems.  I removed most unnecessary calls from Emacs 29.  If that is still slow, then please tell me where the call is.  Emacs should not call _XReply just to redisplay!


On February 25, 2023 4:51:19 AM GMT+08:00, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Spencer Baugh <sbaugh@janestreet.com>
>> Date: Fri, 24 Feb 2023 15:33:52 -0500
>> Cc: emacs-devel@gnu.org,
>>   azeng@janestreet.com
>> 
>> On Fri, Feb 24, 2023 at 3:19 PM Eli Zaretskii <eliz@gnu.org> wrote:
>> >
>> > > From: Spencer Baugh <sbaugh@janestreet.com>
>> > > Date: Fri, 24 Feb 2023 15:08:17 -0500
>> > > Cc: emacs-devel@gnu.org,
>> > >   azeng@janestreet.com
>> > >
>> > > > This is normal.
>> > >
>> > > Just to make sure I understand, you said earlier:
>> > >
>> > > >There are many variables and flags Emacs uses to decide when something
>> > > >changed that needs the display to be updated.  Those should generally
>> > > >prevent Emacs from running the expensive parts of redisplay if they
>> > > >are unnecessary.  The question is why this doesn't work in your case.
>> > >
>> > > Are you saying this does not apply in the case of reading from
>> > > process output? That after reading process output, we always do
>> > > an expensive redisplay?
>> >
>> > Whether redisplay is expensive or not depends on many factors.  But we
>> > always flush the frame in that case, yes.
>> 
>> Why? It seems unnecessary if nothing has changed.
>
>I'm not sure we know that nothing has changed.  I'm also not sure I
>understand why XFlush is so expensive when nothing or almost nothing
>has changed on display.  Maybe Po Lu could comment.
>
>> > AFAIU, what is problematic for you is the X traffic causes by XFlush.
>> 
>> I think that is problematic for anyone running with a slow X server; it
>> gives the X server a lot to process.
>
>Are you sure?  What exactly does XFlush send to the X server if
>nothing was changed on display?
>
>> In other words, I think XFlush should be considered "expensive" and
>> avoided where possible.
>
>If that is possible, I agree.
>



  reply	other threads:[~2023-02-24 23:14 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-17 15:16 Excessive redisplay from lots of process output Spencer Baugh
2023-02-17 16:06 ` Eli Zaretskii
2023-02-17 16:41   ` Spencer Baugh
2023-02-24 19:14   ` Spencer Baugh
2023-02-24 19:34     ` Eli Zaretskii
2023-02-24 20:08       ` Spencer Baugh
2023-02-24 20:19         ` Eli Zaretskii
2023-02-24 20:33           ` Spencer Baugh
2023-02-24 20:51             ` Eli Zaretskii
2023-02-24 23:14               ` Po Lu [this message]
2023-02-24 23:10     ` Po Lu
2023-02-25  7:35       ` Eli Zaretskii
2023-02-25  9:43         ` Po Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5BF9DB30-1CC1-450D-BCAE-A979B06DDE6B@yahoo.com \
    --to=luangruo@yahoo.com \
    --cc=azeng@janestreet.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=sbaugh@janestreet.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).