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 --]
prev parent 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
* 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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.