unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Robert Pluim <rpluim@gmail.com>
To: Michael Stapelberg <stapelberg+emacs@google.com>
Cc: emacs-devel@gnu.org
Subject: Re: x_display_ok() is slow over using SSH X11 forwarding
Date: Wed, 02 Sep 2020 16:56:41 +0200	[thread overview]
Message-ID: <m2tuwg447q.fsf@gmail.com> (raw)
In-Reply-To: <CAH9Oa-a2HWmsxuA7qto2=V03tj-VY=KyhE2bg6VNwLizXiKq+A@mail.gmail.com> (Michael Stapelberg's message of "Wed, 2 Sep 2020 15:48:40 +0200")

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



  reply	other threads:[~2020-09-02 14:56 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 [this message]
2020-12-17 15:44   ` Michael Stapelberg

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=m2tuwg447q.fsf@gmail.com \
    --to=rpluim@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=stapelberg+emacs@google.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).