From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#70036: a fix that Date: Fri, 19 Apr 2024 13:54:23 +0100 Message-ID: References: <4e670617-6483-4159-a5cf-27a921764c38@email.android.com> <865xwddf5w.fsf@gnu.org> 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="33149"; mail-complaints-to="usenet@ciao.gmane.io" Cc: felician.nemeth@gmail.com, 70036@debbugs.gnu.org, Theodor Thornhill To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Apr 19 14:55:09 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1rxnll-0008Mc-AS for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 19 Apr 2024 14:55:09 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rxnlS-0000IY-M0; Fri, 19 Apr 2024 08:54:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rxnlQ-0000He-Lm for bug-gnu-emacs@gnu.org; Fri, 19 Apr 2024 08:54:48 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rxnlQ-0005Xe-Ac for bug-gnu-emacs@gnu.org; Fri, 19 Apr 2024 08:54:48 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rxnle-0005UX-10 for bug-gnu-emacs@gnu.org; Fri, 19 Apr 2024 08:55:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 19 Apr 2024 12:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70036 X-GNU-PR-Package: emacs Original-Received: via spool by 70036-submit@debbugs.gnu.org id=B70036.171353129921085 (code B ref 70036); Fri, 19 Apr 2024 12:55:01 +0000 Original-Received: (at 70036) by debbugs.gnu.org; 19 Apr 2024 12:54:59 +0000 Original-Received: from localhost ([127.0.0.1]:58273 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rxnla-0005U0-Ol for submit@debbugs.gnu.org; Fri, 19 Apr 2024 08:54:59 -0400 Original-Received: from mail-lj1-x230.google.com ([2a00:1450:4864:20::230]:53342) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rxnlY-0005Sj-9X for 70036@debbugs.gnu.org; Fri, 19 Apr 2024 08:54:57 -0400 Original-Received: by mail-lj1-x230.google.com with SMTP id 38308e7fff4ca-2db2f6cb312so37097741fa.2 for <70036@debbugs.gnu.org>; Fri, 19 Apr 2024 05:54:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713531276; x=1714136076; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=OvT2EJQSp+R+oPdMFNZvuetqf3imcvvj3Ne/Gj8KT5U=; b=ZxHMiXBfzGdOOYOhpjoJf1osfG4A3VypUPpaaTRAbm3Ijc0C+1sTDNnHXd3oyzbxJn utNV1NYw2sEqKPVvt1jPnM7ZN9uaW6eShbrpprAPm0KsntV0qufNtmTAzkgOUqgi+Fgb LAbomZRj0kWI63VHFYuBt9vYfYNjlh2CxSuf6E94lGxNAXONUcROclFY+7+K4WrrkdNM OQimr+G8WWE0HsY0tOe6tepTPl+23mt26Y1n1f4IXBGVaQR1Uu4Ibf+NEhOGEGdenDpv vAMkrjv86HnhZiJct/kdPtFVWHwXEkVys+a8poLyOSp5ARnD0wJ519GCgGjXE6l7Yi57 HkAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713531276; x=1714136076; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=OvT2EJQSp+R+oPdMFNZvuetqf3imcvvj3Ne/Gj8KT5U=; b=ELYuJWkGm+x2haoe7S5b8sl3SCBpLuO0/vPh3SLlNwTmV8OC1oEdm8hW2x0IF5nPhX iXBWP6PkZ62ZJyoWzoS6pajIB0TiiLysWDU7eVjzdfGpqcXsXqVTcqQjCFAFGaETePXX zEovJjjzJT/s+hl7Jk2+H71Oq8lqbILN/+AKNozX8cigbmi3h78evAMmo47VX+mfksZQ zblS3dfnIPNd/1/jR/F++3hNK1t/JJPwvstZ0ZvrnRwnBss7m/qYc7vcFI/VfV1RY2EI 3JhZhhJ081oHLca28BCt2ciHv7VOSS/k1rG/GLpy9/eA5LOntQzzRzFElK/DDxTwUDV3 QE8g== X-Forwarded-Encrypted: i=1; AJvYcCVebqF3OCfBZSMaUabQpHIr+6m3aFESFxqDMO66/5iE8YtsP/yjxhbgWvj2lb9whMKQTeeEi4IgcjTnNOV6s35mNLTwR7Y= X-Gm-Message-State: AOJu0YyQ4JVCco7iBHVRcxpzCLB94BiAD6oVdP29CUTtV5d2mG3NOMrF 4zVgY7WNESsMMGZOk/AP3fy5aKkGmYllSmuD0pDCIQWHGpcpDaxK+zfzK8xfJCXXAi0IdsxhZvJ Kd198ez02ZwEsM2LS1TMO3YatKCo= X-Google-Smtp-Source: AGHT+IFVxPFGzNQRYIzrsKBidVSEZjtDlc8lx9nFnEe+T5fFvCAInCwxpbNII6qg43pn+JBnhVpMt39zA+96yzQT5SI= X-Received: by 2002:a05:651c:2214:b0:2d8:5af9:90c5 with SMTP id y20-20020a05651c221400b002d85af990c5mr2040893ljq.39.1713531275955; Fri, 19 Apr 2024 05:54:35 -0700 (PDT) In-Reply-To: <865xwddf5w.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:283683 Archived-At: On Fri, Apr 19, 2024 at 7:45=E2=80=AFAM Eli Zaretskii wrote: > Thanks, but that is not what I asked to provide, for us to make a > decision in this case. > Could you please show benchmark times of the old code (before your > changes), the code after your changes, and the current code in Git I just noticed this and think a comment needs to be made about Eglot and performance measurements specifically. If a good `benchmark-run` or invocation can be made to measure a specific problem, it is usually a very good tool. But in Eglot, it's rare (*) What some in this discussion may not understand is that Eglot works mostly asynchronously. The user invokes commands that ask something of the server and that server will later respond with something that is hopefully still relevant somehow. On-the-fly diagnostics work like this, and even startup can be asynchronous. So any slowdowns are usually felt subjectivel= y in input lag across a session where the user is doing some work. More often than not, there isn't a (benchamark-run 10 (eglot-foo )) that can tell us something useful. It's more like "I feel diagnostics take longer to appear", "ElDoc spins my CPU fan", "completions feel laggy", and things like that. Of course, special Elisp code can be crafted to simulate how a user interacts with Eglot, but that's not always easy due to the need to mock complex objects (the server object, notably) and the aforementioned async nature. So that's why the best way to communicate these problems is via a profile accompanied by the usual bullet-proof Emacs -Q recipe. It should contain a clear description of when profiler-start and profiler-stop are invoked, and what the user did in between. And that's _exactly_ what Theo did here, and was useful to me: I reproduced his results perfectly. Those profiles easily tell us who the hotspots are at the Elisp level. That's IF the hotspots are even at the Elisp level, because often a slow-responding server is all it takes. In those cases Eglot/Elisp may or may not be "off the hook", depending on whether the cause for server slowness is some earlier misconfiguration that is ultimately Eglot's fault. Maybe some of this info should be added to the Eglot manual in its troubleshooting section. Jo=C3=A3o (*) The eglot--glob section is a notable exception. I used benchmark-run to optimize back then.