unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Michael Stapelberg <stapelberg+emacs@google.com>
To: Robert Pluim <rpluim@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: x_display_ok() is slow over using SSH X11 forwarding
Date: Thu, 17 Dec 2020 16:44:26 +0100	[thread overview]
Message-ID: <CAH9Oa-bB_YziSCpkhSd1JQTW3cb+qL8afMEvZwk+weEkEtLdpg@mail.gmail.com> (raw)
In-Reply-To: <m2tuwg447q.fsf@gmail.com>

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

Sorry for letting this linger for so long. Answers inline:

On Wed, 2 Sept 2020 at 16:56, Robert Pluim <rpluim@gmail.com> wrote:

> >>>>> On Wed, 2 Sep 2020 15:48:40 +0200, Michael Stapelberg <
> stapelberg+emacs@google.com> said:
>     Michael> I have discovered that Emacs opens 4 (!) X11 connections when
> a new Emacs
>     Michael> process opens a frame:
> https://twitter.com/zekjur/status/1293892602274746370
>
> Thatʼs only the first time emacs starts, no? Subsequent make-frames
> should skip at least two of those. Or are you starting emacs every
> time? In that case Iʼd investigate M-x server-start and/or daemon
> mode.
>

I am starting one Emacs daemon per workspace,
and workspace switching is frequent enough in my workflow that it matters.

I have tried repeatedly to change this workflow to just one long-running
Emacs daemon,
but dislike that actions on one workspace can influence how Emacs behaves
on another workspace.
Thus, this model never worked for me, and I prefer my separate Emacs
(daemon) instances after all…


>
>     Michael> I then measured how long opening an X11 connection takes, and
> found that
>     Michael> when using SSH X11 forwarding, opening an X11 connection is
> really slow
>     Michael> (≈120ms) compared to locally (≈0.5ms):
>     Michael> https://twitter.com/zekjur/status/1296763221936939010
>
>     Michael> It turns out that 2 of the 4 connections are made by
> x_display_ok(), which
>     Michael> can easily be short-circuited to verify:
>     Michael> https://twitter.com/zekjur/status/1298002575267110919.
>     Michael> Setting NO_AT_BRIDGE=1 removes the third connection.
>
>     Michael> Now, entirely short-circuiting that function is a big hammer,
> and probably
>     Michael> we don’t want to break existing users of x_display_ok(), but
> I do wonder
>     Michael> what the best way to remove these unnecessary connection
> attempts is?
>
>     Michael> From a high-level perspective, the current behavior is
> unnecessary because:
>
>     Michael> 1. If the X11 $DISPLAY variable is not okay, I’ll get an
> error message
>     Michael> anyway.
>
>     Michael> 2. Just because $DISPLAY worked at the time of check doesn’t
> mean it’ll
>     Michael> work at time of use.
>
>     Michael> 3. Even if checking is desired, there is no need to check
> twice during
>     Michael> startup, and we should retain the connection used for
> checking so that we
>     Michael> don’t need to connect over and over.
>
> Retaining the connection would require quite a bit of work. Besides,
> your initial display might not be the same as the one you open
> subsequent frames on. Having said that, this should reduce it
> slightly (Iʼve not tested it in all combinations of toolkits yet):
>

I can confirm that this patch removes 1 X11 connection from Emacs startup
for me.

Can you go ahead and submit the change please?

Thank you :)

Happy holidays,


>
> diff --git a/src/xterm.c b/src/xterm.c
> index 2e0407aff4..448e06eb8b 100644
> --- a/src/xterm.c
> +++ b/src/xterm.c
> @@ -12709,8 +12709,6 @@ x_term_init (Lisp_Object display_name, char
> *xrm_option, char *resource_name)
>        ++x_initialized;
>      }
>
> -  if (! x_display_ok (SSDATA (display_name)))
> -    error ("Display %s can't be opened", SSDATA (display_name));
>
>  #ifdef USE_GTK
>    {
> @@ -12838,6 +12836,7 @@ #define NUM_ARGV 10
>    /* Detect failure.  */
>    if (dpy == 0)
>      {
> +      error ("Display %s can't be opened", SSDATA (display_name));
>        unblock_input ();
>        return 0;
>      }
>

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

      reply	other threads:[~2020-12-17 15:44 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-02 13:48 x_display_ok() is slow over using SSH X11 forwarding Michael Stapelberg
2020-09-02 14:56 ` Robert Pluim
2020-12-17 15:44   ` Michael Stapelberg [this message]

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=CAH9Oa-bB_YziSCpkhSd1JQTW3cb+qL8afMEvZwk+weEkEtLdpg@mail.gmail.com \
    --to=stapelberg+emacs@google.com \
    --cc=emacs-devel@gnu.org \
    --cc=rpluim@gmail.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).