x_display_ok() is slow over using SSH X11 forwarding

x_display_ok() is slow over using SSH X11 forwarding

[Michael Stapelberg]

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

Hey,

Like undoubtedly many of you, I started Working From Home a while ago and
will continue to do so for some time.

I am using Emacs over SSH’s X11 forwarding, which—for various reasons—is
the best setup for me, and yes, I have already tried numerous others
(TRAMP, remote desktop, nx, xpra, …).

The one issue I have with my setup is that Emacs takes a noticeably long
time to open a new frame (X11 window).

I have discovered that Emacs opens 4 (!) X11 connections when a new Emacs
process opens a frame: https://twitter.com/zekjur/status/1293892602274746370

I then measured how long opening an X11 connection takes, and found that
when using SSH X11 forwarding, opening an X11 connection is really slow
(≈120ms) compared to locally (≈0.5ms):
https://twitter.com/zekjur/status/1296763221936939010

It turns out that 2 of the 4 connections are made by x_display_ok(), which
can easily be short-circuited to verify:
https://twitter.com/zekjur/status/1298002575267110919.
Setting NO_AT_BRIDGE=1 removes the third connection.

Now, entirely short-circuiting that function is a big hammer, and probably
we don’t want to break existing users of x_display_ok(), but I do wonder
what the best way to remove these unnecessary connection attempts is?

From a high-level perspective, the current behavior is unnecessary because:

1. If the X11 $DISPLAY variable is not okay, I’ll get an error message
anyway.

2. Just because $DISPLAY worked at the time of check doesn’t mean it’ll
work at time of use.

3. Even if checking is desired, there is no need to check twice during
startup, and we should retain the connection used for checking so that we
don’t need to connect over and over.

Any thoughts?

Thanks,

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

Re: x_display_ok() is slow over using SSH X11 forwarding

[Robert Pluim]

>>>>> 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.

    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):

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;
     }

Re: x_display_ok() is slow over using SSH X11 forwarding

[Michael Stapelberg]

[-- 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 --]