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: Thu, 18 Apr 2024 17:12:34 +0100 Message-ID: References: <86y19ad61t.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="29807"; 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 Thu Apr 18 18:14:02 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 1rxUOf-0007VS-PX for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 18 Apr 2024 18:14:01 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rxUOX-0004GV-EA; Thu, 18 Apr 2024 12:13:53 -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 1rxUOS-0004GB-Nx for bug-gnu-emacs@gnu.org; Thu, 18 Apr 2024 12:13: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 1rxUOS-00078R-De for bug-gnu-emacs@gnu.org; Thu, 18 Apr 2024 12:13:48 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rxUOf-0004ud-Tg for bug-gnu-emacs@gnu.org; Thu, 18 Apr 2024 12:14:01 -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: Thu, 18 Apr 2024 16:14: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.171345679118540 (code B ref 70036); Thu, 18 Apr 2024 16:14:01 +0000 Original-Received: (at 70036) by debbugs.gnu.org; 18 Apr 2024 16:13:11 +0000 Original-Received: from localhost ([127.0.0.1]:53260 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rxUNp-0004oa-DF for submit@debbugs.gnu.org; Thu, 18 Apr 2024 12:13:10 -0400 Original-Received: from mail-lf1-x12d.google.com ([2a00:1450:4864:20::12d]:44364) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rxUNm-0004nI-GD for 70036@debbugs.gnu.org; Thu, 18 Apr 2024 12:13:07 -0400 Original-Received: by mail-lf1-x12d.google.com with SMTP id 2adb3069b0e04-516d3776334so1247079e87.1 for <70036@debbugs.gnu.org>; Thu, 18 Apr 2024 09:12:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713456767; x=1714061567; 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=lnHSRGSxl0tTNixux9stkcM18PxshHbVbs8DfZzPUy0=; b=aAJP91O09gATWVltBUBoU62z0+OZES/Q6IaqGbeXnnF9JekqrFmKdWrxtY2V5xaFfn SNXPLbFGjdxq5JDEhfO3aG4znDy9T3wmo6LlDEAfeqkdGIS7mxvcM7qD9XofEYIO9sTF 1bUNLg+kAUulvL9IUozOiiKsIlievUlGrx5bkDz15agDL6kX++oJiiYx7UuKIdrRe2Du 56ofhGLC7BzoB46Qm+i74tdeWtRNWP9UpSiUcefkd6tbZPnbIDuRuoAnWpUpUAvh6PE7 u0HUpJwRNe5qdw7gXD7CRkY43dMUltf8GjJ7izjHMISia8Nn55Vjj9+PmG6K8Hf8bnNO vG6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713456767; x=1714061567; 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=lnHSRGSxl0tTNixux9stkcM18PxshHbVbs8DfZzPUy0=; b=ZVmQlF+/w63JP8SMV+rVdaeJBGEtdZggEoQzGntps9BuKIbGJywJbiZir25LVgY0KL QaVK2g238y6sERLd8SN6HLMQMdqgiQEdaQ2eD3fpLE3H1eIvynEkbui1nC7gfRJ6AplL Gky6gqpiEDOyOxSb+HqARLnn/k+LP4rC4neF3/EbF23MUtpps+WqQuD+sVx8kct6ZWRy RFsDK7fgV7ucL0Y9Zuz1O5A16wLDkWqmEykyrJIapx8ewqTqGXpspMNk7gi6nAq+UIqG 6A+x2VJjIiHjGBCNJzeFfZGxtSdVzowLMO969sall0OjMOBgVjbuHlP9XirsYycISALJ Ml6w== X-Forwarded-Encrypted: i=1; AJvYcCUg/ElPpna5FNWgONRtkviH72Fs0c9Vn2wy7EF553Ep2Bs3DQ0Jdc8Vuk3CUtzqg9KylNL1+/1GGYOxi53amNnTQusJpxk= X-Gm-Message-State: AOJu0YzuMOeDGD6i6FJ28nhZznSWXSL/uAktYt5gIyBxmcV/aCcs2iHT uIoCByue/1sC2td6yBg8l46G63igCbomHl1NypKuRBIYzEasoFpahpuD4j1LRRocKGq/lByb4av ngy05TUGEhGB53zkeANNwJ8ngfcw= X-Google-Smtp-Source: AGHT+IEFh5dmE/Z4TE7trARY8FQVXS9wZEY0Kqltse8Tmfxk6vkmgmQwoeiwpv3cgTumPC+IOGJdE7QHVp1+GQ8nDMI= X-Received: by 2002:ac2:4256:0:b0:51a:62ad:461f with SMTP id m22-20020ac24256000000b0051a62ad461fmr822588lfl.12.1713456766556; Thu, 18 Apr 2024 09:12:46 -0700 (PDT) In-Reply-To: <86y19ad61t.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:283582 Archived-At: On Thu, Apr 18, 2024 at 4:49=E2=80=AFPM Eli Zaretskii wrote: > > > From: Jo=C3=A3o T=C3=A1vora > > Date: Thu, 18 Apr 2024 16:32:33 +0100 > > Cc: Eli Zaretskii , 70036@debbugs.gnu.org > > > > So I've read up on the bug report and I had a close look at the Eglot > > usage profiles (not the micro-benchmarks, those are reasonably > > irrelevant in what concerns Eglot). I see these kinds of things in > > Theodor's profiles > > > > 18 8% - eglot--TextDocumentPositionParams > > 18 8% - eglot--TextDocumentIdentifier > > 18 8% - eglot--path-to-uri > > 15 7% - file-truename > > 14 6% - file-truename > > 14 6% - file-truename > > 11 5% - file-truename > > 11 5% - file-truename > > 11 5% - file-truename > > 10 4% - file-truename > > 10 4% - file-truename > > 8 3% - file-truename > > 8 3% - file-truename > > 8 3% - file-truename > > 5 2% - file-truename > > 3 1% - file-truename > > 2 0% - file-truename > > 1 0% file-truename > > > > > > I could reproduce this, but never even close to the amount of ~7-8%. > > Best I could get was 1% and I had to work pretty hard for it. If I > > invoke completion or something heavier like that, it completely > > dominates the profile. > > > > 25 1% - eglot--TextDocumentPositionParams > > 23 1% - eglot--TextDocumentIdentifier > > 23 1% - eglot-path-to-uri > > 13 0% - file-truename > > 13 0% - file-truename > > 13 0% - file-truename > > 13 0% file-truename > > > > Maybe that's because file-truename is a recursive function that becomes > > slower as the path it's asked to analyse becomes longer (obviously, > > there can be a symlink at every junction). > > Profiles can mislead and they can lie. Theo's profiles attached to this issue were the best I could find. If the manner in which they were collected was enough to make a decision in a certainway, they should be good enough to make a decision in another way. But I fully agree we should have a more constrained test case. > It is much easier to time the > old and the new code doing the same jobs, and compare the times. So... that's what I did. As I wrote, I first reproduced (a fraction of) Theo's findings with the old code (before his patch). Then in the latest master his patch, added my new patch, and verified that the newest code no longer reproduces those findings. Do you have a concrete idea of what this "job" is? I could only gather a moderately useful idea from Theo's profiles, but it wasn't vague by any means. It seems his "timer-event-handler" which is usually doing the work for Eglot's at-point documentation job, is spending about a quarter of its time in file-truename. That's typical when just browsing code with the cursor and reading documentation. > > If so, I think this simpler patch after my sig is all we need, as it > > completely clears the profile of any "file-truename". I have reverted > > the earlier patch and pushed a patch very similar to the one after my s= ig. > > This new code should also be timed and compared to the other two > versions, before we make the final decision on this. Of course. Let's have Theo do this comparison and perhaps describe in more detail the conditions in which he collected his profiles