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:00:54 +0100 Message-ID: References: <4e670617-6483-4159-a5cf-27a921764c38@email.android.com> <864jbxden1.fsf@gnu.org> <86r0f1bopx.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="33109"; mail-complaints-to="usenet@ciao.gmane.io" Cc: felician.nemeth@gmail.com, 70036@debbugs.gnu.org, theo@thornhill.no To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Apr 19 14:02:29 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 1rxmwm-0008OM-OE for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 19 Apr 2024 14:02:28 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rxmwC-0002xl-DK; Fri, 19 Apr 2024 08:01:52 -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 1rxmwA-0002wX-C1 for bug-gnu-emacs@gnu.org; Fri, 19 Apr 2024 08:01:50 -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 1rxmwA-0003XO-3Q for bug-gnu-emacs@gnu.org; Fri, 19 Apr 2024 08:01:50 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rxmwO-0007e2-4c for bug-gnu-emacs@gnu.org; Fri, 19 Apr 2024 08:02:04 -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:02:04 +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.171352808829055 (code B ref 70036); Fri, 19 Apr 2024 12:02:04 +0000 Original-Received: (at 70036) by debbugs.gnu.org; 19 Apr 2024 12:01:28 +0000 Original-Received: from localhost ([127.0.0.1]:58200 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rxmvo-0007YW-Ae for submit@debbugs.gnu.org; Fri, 19 Apr 2024 08:01:28 -0400 Original-Received: from mail-lj1-x236.google.com ([2a00:1450:4864:20::236]:42178) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rxmvm-0007XD-4g for 70036@debbugs.gnu.org; Fri, 19 Apr 2024 08:01:27 -0400 Original-Received: by mail-lj1-x236.google.com with SMTP id 38308e7fff4ca-2db101c11feso13380761fa.0 for <70036@debbugs.gnu.org>; Fri, 19 Apr 2024 05:01:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713528066; x=1714132866; 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=hwwnHLA3ZUR43zySo9CpuCTUOuoM5OsizwapW11ebYc=; b=gi4ovb0UAGMz4ZNzwUZHxQfdOA85MxdrjS6Ew6rbMjPp/MM8R9TCgvzDK6QlSRqB+K zaw3VfeSuIN8rrBx3D3PCLQvNf5RpiRVqyCkJ8uG/79p1ELcpeagilv/eNblT05sWlY6 d+O8APuBlV6sDEReyXFwFrvl6/ralr60J8jleq2/Zb4hUWPIQ2+oWPpYgyfo1Qk5RvEF GRrFYCj2ZePelWn6BZxXRZHfHQooBJHgrYVUDsNrSD6Pv2Af/VxVnnnlh8JD333VZhJt F/fBTQ6t9Aa35Pp2kcvNI2TySrM0Cpx/oYn1biVbzl6+VoLBxUcgYz84Cz0IEG4zfcCT s68A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713528066; x=1714132866; 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=hwwnHLA3ZUR43zySo9CpuCTUOuoM5OsizwapW11ebYc=; b=LK/vcGfoOnP5nfy8OgUrw9uhfypRtwFXPbCbf5gW3nZ494d8/7P3ZrHk4D4XUY6KZV KQo+auRkYEFC/nyH+Hy76MerAx1OFo1d72bNfxPESbSV6tHpVnEp7orO1o3NoiE3VGK/ Wqi5eFzdIccx3FpqJKLs2AuMWlsB1C/hCd9CJnXIkyfFvxft/13pYXMttyh87r/rF7A+ I4r0BQ7lNIeiR2c1MJlvvrg3fy/BUP7ozR7pSHJhIuBRqnNpCqxNCnWMsif9STPzchkT bX5y5OfDs+DWzzegzkQo/YcgBda3ncGhNQAxxCDYyoklA6MB7d8/rRpOWXxSdpad7jj2 n7dg== X-Forwarded-Encrypted: i=1; AJvYcCV2n8L+7iIxYVvXPWFrKEbLVAyYNBvmB6mW8SbUV4Rdc38QQ+z0GDmk6UKW7UZPQ28sSbJw4AynY1wujybICAvxlmFdCnY= X-Gm-Message-State: AOJu0YymVBTiPE405hO1AV92pC8pDdfpCwped4SOYd+w1PwESvcYF3q+ TY0DiXTMp2MJNtel/4EQIDte7ixWAp6W7pZwhP+Gez5QDSvqr6lCfuVA9dyolsAyadmOvSV2y0K bqYb/Gd56sMnA2aAr+dNqCNXJvF0= X-Google-Smtp-Source: AGHT+IFv14pUrePhrVaj4ob7kv87oP+X5Yo9Skpaq+200yj+OjjfqXI/uXsB6h9m0FPof7iBsNekliXr8tpnH61rg+4= X-Received: by 2002:a2e:8752:0:b0:2d8:49e8:3132 with SMTP id q18-20020a2e8752000000b002d849e83132mr698013ljj.0.1713528065608; Fri, 19 Apr 2024 05:01:05 -0700 (PDT) In-Reply-To: <86r0f1bopx.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:283677 Archived-At: On Fri, Apr 19, 2024 at 12:01=E2=80=AFPM Eli Zaretskii wrote= : > No, IMO we should try it in both "emacs -Q" and in a session with a > lot of buffers, to have the performance in its true relevant context. > Most real-life Emacs sessions have many more buffers than we have in > "emacs -Q". Worst-case testing is not always TRT, because it can skew > the perspective and lead to wrong decisions. The worst case here is relative. It's also a very plausible case in the sense that starting Emacs, navigating to a file of a project you're working on, and pressing M-x eglot is probably one of the most common things you do with Eglot. So IOW the worst case is also the common one. > > > But if calling > > > find-buffer-visiting from Eglot can be avoided, that is of course eve= n > > > better. > > > > Yes, that's what my latest patch does. But ideally it would be cleaner > > (IMHO) to have a fast usable find-buffer-visiting by speeding > > up its underlying file-truename. > > We did that at least to some extent in the improvements submitted by > Ihor and now available on master. From where I stand, we now have a > reasonably performant implementation of find-buffer-visiting; I would > need benchmarks showing otherwise to change my mind. Theo's latest measurements show that -- in context -- there is a 4% time spent in find-buffer-visiting and all of that is due to its delegation of work to file-truename. Does that change your mind? I reproduced the measurements but personally didn't feel this in any way problematic (in my machine) to the use of Eglot. But Theo says there are Java projects that run much, much worse and with much more friction, but he can't share the data with us for other reasons. So it didn't really change _my_ mind. For _me_ `f-b-v` was reasonably fast enough when running Theo's recipe and definitely fast enough when trying any other project. But what changes my mind is the fact that: * I believe Theo is telling the truth that it's a much bigger bottleneck in Java projects. * the workaround isn't _that_ ugly. In summary, I still think f-b-v use in Eglot's publishDiagnostics handler i= s cleanest conceptually, but because I believe Theo that it's a serious bottleneck, I'm not opposed to skipping it with the alternative technique already presented. Jo=C3=A3o