From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Robert Pluim Newsgroups: gmane.emacs.devel Subject: Re: x_display_ok() is slow over using SSH X11 forwarding Date: Wed, 02 Sep 2020 16:56:41 +0200 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11312"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Michael Stapelberg Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Sep 02 16:57:19 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kDUCM-0002oe-QG for ged-emacs-devel@m.gmane-mx.org; Wed, 02 Sep 2020 16:57:18 +0200 Original-Received: from localhost ([::1]:42582 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kDUCL-00037t-Sh for ged-emacs-devel@m.gmane-mx.org; Wed, 02 Sep 2020 10:57:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38892) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kDUBs-0002fO-ID for emacs-devel@gnu.org; Wed, 02 Sep 2020 10:56:48 -0400 Original-Received: from mail-wr1-x42b.google.com ([2a00:1450:4864:20::42b]:34630) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kDUBq-0005BW-Sc for emacs-devel@gnu.org; Wed, 02 Sep 2020 10:56:48 -0400 Original-Received: by mail-wr1-x42b.google.com with SMTP id t10so4738364wrv.1 for ; Wed, 02 Sep 2020 07:56:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:gmane-reply-to-list:date:in-reply-to :message-id:mime-version:content-transfer-encoding; bh=6H7KYFMIr7EUFCKGG2tR1TKjgDsnBlXHEowhGwiyqFU=; b=Pki1dG0AZSX/vjRuzxmtxWo21MBH4OrvUn0EFK6UqNhZolP4MEfxpWVtv+7BMV33uU TQFdTbk/5JjQYMLWWu06+plGd97aIi2laFvl+wZK39ScDpAPXFqKBes4rB/njs+PcbgB r/y1vLGyzm/GHTPCORi9M70cMNGiHKY5fGI6LS9MhzgzTtJZyKm1U6KqiKndb29a5Ck4 MSwzqK2+CVoymib/v+vsMFx503uWC71EjziZuSbUy9xCmxEpgASqhuc4T0xxg2OkfS/1 MluKPW1JQVCj0CfDuEMI5GUNGM9W/m8q/J90NQm6Zp7slhU4OwqS6gwTBcDiGcRMcuU8 vBhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references :gmane-reply-to-list:date:in-reply-to:message-id:mime-version :content-transfer-encoding; bh=6H7KYFMIr7EUFCKGG2tR1TKjgDsnBlXHEowhGwiyqFU=; b=eRj4VaG9uRWyRcsp8YeHc6/MQK+dozigNxUPyRs2fs/8qPiOpHE3iloBIlBqyRWOjA 8VY4EPtV7kOPHCfBazxN1D5r1M8CNzWQuH+x2EEAS31QmhjCXo1jQ0o+VbcWHd3usO16 w7Ff1beuCnrrAfQqDtEhCmMFC50Wx7KNjhTjk538NHjy4zyoMwzbihwJb1gqaN9vS/PM RWaAYQcFpDjCDVLtb7z2BVAvwbiMYbyAKh2dSOO1U7heGKgffDHcVyzGmIWvq8tpZeah Putn3v7xsbr7i9a9qCdEMzu48yISQilSLUJH2KaYtR2BiAWTEnIUAsX/WhhR4U+Wkscv NLXQ== X-Gm-Message-State: AOAM533J1R7HtWtQ7B1tJh2ipBKIyE1fbWIoCnKUd+WJd1SSRUIRw0aa aQkkIsFmfoPq1XFZwv62P12N0uz8gNe/hA== X-Google-Smtp-Source: ABdhPJyUxl+6rDvlTDq9meNI9uYHNAaa1DbJE38dDUMtDHNc1epWOcVuVy1gWPqekJ/D2RBsmzKANA== X-Received: by 2002:adf:ba10:: with SMTP id o16mr7549546wrg.100.1599058603145; Wed, 02 Sep 2020 07:56:43 -0700 (PDT) Original-Received: from rpluim-mac ([2a01:e34:ecfc:a860:871:26a6:64eb:9c90]) by smtp.gmail.com with ESMTPSA id r129sm7041330wmr.40.2020.09.02.07.56.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Sep 2020 07:56:42 -0700 (PDT) Gmane-Reply-To-List: yes In-Reply-To: (Michael Stapelberg's message of "Wed, 2 Sep 2020 15:48:40 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::42b; envelope-from=rpluim@gmail.com; helo=mail-wr1-x42b.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:254483 Archived-At: >>>>> On Wed, 2 Sep 2020 15:48:40 +0200, Michael Stapelberg 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/12938= 92602274746370 That=CA=BCs 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=CA=BCd 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 re= ally slow Michael> (=E2=89=88120ms) compared to locally (=E2=89=880.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=3D1 removes the third connection. Michael> Now, entirely short-circuiting that function is a big hammer, = and probably Michael> we don=E2=80=99t want to break existing users of x_display_ok(= ), but I do wonder Michael> what the best way to remove these unnecessary connection attem= pts is? Michael> From a high-level perspective, the current behavior is unneces= sary because: Michael> 1. If the X11 $DISPLAY variable is not okay, I=E2=80=99ll get = an error message Michael> anyway. Michael> 2. Just because $DISPLAY worked at the time of check doesn=E2= =80=99t mean it=E2=80=99ll Michael> work at time of use. Michael> 3. Even if checking is desired, there is no need to check twic= e during Michael> startup, and we should retain the connection used for checking= so that we Michael> don=E2=80=99t 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=CA=BCve 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_op= tion, char *resource_name) ++x_initialized; } =20 - if (! x_display_ok (SSDATA (display_name))) - error ("Display %s can't be opened", SSDATA (display_name)); =20 #ifdef USE_GTK { @@ -12838,6 +12836,7 @@ #define NUM_ARGV 10 /* Detect failure. */ if (dpy =3D=3D 0) { + error ("Display %s can't be opened", SSDATA (display_name)); unblock_input (); return 0; }