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#47711: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Date: Tue, 31 Oct 2023 10:55:44 +0000 Message-ID: References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@yandex.ru> <83fsvcbio7.fsf@gnu.org> <9f432d18-e70f-54c1-0173-1899fb66d176@gutov.dev> <877cnafv39.fsf@gmail.com> <9447dde3-b8e7-2ec0-9a9c-72c4cf9d12a8@gutov.dev> <7d14bc13-4419-816c-5708-c42988c39c02@gutov.dev> <5d0a78cc-4fa0-ef04-3462-1826f17d7d56@gutov.dev> <877cn8asud.fsf@gmail.com> <8734xtauqj.fsf@gmail.com> 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="29243"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Daniel Mendler , Eli Zaretskii , Stefan Monnier , 47711@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Oct 31 11:56:53 2023 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 1qxmQW-0007Qp-Qp for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 31 Oct 2023 11:56:52 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qxmQA-0005Y5-A7; Tue, 31 Oct 2023 06:56:30 -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 1qxmQ9-0005Xv-0n for bug-gnu-emacs@gnu.org; Tue, 31 Oct 2023 06:56:29 -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 1qxmQ8-0003AB-OM for bug-gnu-emacs@gnu.org; Tue, 31 Oct 2023 06:56:28 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qxmQg-0005sW-Dq for bug-gnu-emacs@gnu.org; Tue, 31 Oct 2023 06:57: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: Tue, 31 Oct 2023 10:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 47711 X-GNU-PR-Package: emacs Original-Received: via spool by 47711-submit@debbugs.gnu.org id=B47711.169874979722562 (code B ref 47711); Tue, 31 Oct 2023 10:57:02 +0000 Original-Received: (at 47711) by debbugs.gnu.org; 31 Oct 2023 10:56:37 +0000 Original-Received: from localhost ([127.0.0.1]:47515 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qxmQH-0005rq-7I for submit@debbugs.gnu.org; Tue, 31 Oct 2023 06:56:37 -0400 Original-Received: from mail-lf1-x133.google.com ([2a00:1450:4864:20::133]:48327) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qxmQG-0005rc-5G for 47711@debbugs.gnu.org; Tue, 31 Oct 2023 06:56:36 -0400 Original-Received: by mail-lf1-x133.google.com with SMTP id 2adb3069b0e04-507a62d4788so8403840e87.0 for <47711@debbugs.gnu.org>; Tue, 31 Oct 2023 03:56:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698749756; x=1699354556; 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=kzwa/Xk1YNxVNUHSZKfMTsmFgqRUYeZJ1ee4pc/pL6k=; b=L8lfuzteBPjYWJDwlHHtVnUCpXKaZplsrL6GkqCmb5UxC1qsjdIXjPhOOyKtFvo4S1 bJP3bSGhqKEDnRyk5GSZI0LbBJ46PvAQirn/RQtgjm8jHjgzTuyKf1pxSW4iBGWMlDIt T0yXbbRR7g03d3n2nVkDmW0dmJPEw56Ty/EMSGQ+tHcEbsvRMwmSeIdL0cUPQZ+WFjgV w2+w8WgH2y8a5doXfd2R3xfyFhaQNpuZvlcokLaqIif3DwFLq5AOSlh5Zhu8EoYoHPTj b61PVZdqO9BbTeQ9lTaA7+mpSE7GL+nbyUCT5koiA97vjH4HTvRYGsYFzsLWXiJs4JZI 3GmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698749756; x=1699354556; 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=kzwa/Xk1YNxVNUHSZKfMTsmFgqRUYeZJ1ee4pc/pL6k=; b=vbwS3Sytb9bzwbGzQ6fukeYgrsYNEgZFUNa/JC780vBTuZtgBsGP0eih5YuaS7FrMU MoXNiq6yFThZ8KQj+PDSoYSBZwHAnj5Xkc3R2eix/gCVIbQy4iW3m2hVfC6ROqBrcaYZ H6D4wQeDy0aphUue3LNfUNVc6PaXzoQc4xdRb8rRf9A8PKruKX5I39qZm/G4EhgYstXU O6jFEzHiTvQB4ZBFbMtbSf/+DJl5ozq9w7r/bxU/NzeFcPDIxh8QNkOX1hIb63s9Xx+I QPG1l8qweVE3Enbrv/V04m+8hdGEvU/xpM4Y0MF2KLZ1nY45gV3GH/OdQt8LjDK1z+uC jaVA== X-Gm-Message-State: AOJu0Yx64KFlbJ5tEJz2v+JZBsbpIQT5YwRCXteuTLlTkvqz/g3pHj8a GT+gKTQteWNHIghlAQ8cFW/QMN5Q1RQMitnfmkU= X-Google-Smtp-Source: AGHT+IGziVd13EFIU13Wszb9q5Mn4TsIBJ7W08ntxfbUMFXMLOgYKSfjG5irA3DKUSJRmA+LvHp/FuEJmk4t/KJ/TCw= X-Received: by 2002:a05:6512:3d0b:b0:500:9f7b:e6a4 with SMTP id d11-20020a0565123d0b00b005009f7be6a4mr11216049lfv.32.1698749756209; Tue, 31 Oct 2023 03:55:56 -0700 (PDT) In-Reply-To: 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:273561 Archived-At: On Tue, Oct 31, 2023 at 3:20=E2=80=AFAM Dmitry Gutov wro= te: > > Hi Joao, > > On 30/10/2023 01:12, Jo=C3=A3o T=C3=A1vora wrote: > > >> Thanks. My measurements are similar, except the difference switch the > >> other way a little bit. It might depend on the particulars of the > >> individual machine anyway. > > > > Yes, it could, but I've reproduced this in different hardware. > > > > Check that you're taking enough samples, I take about 15-20 samples. > > Maybe the lazy-hilit patch pays a an extra cost upfront for the very > > first C-h v or completing-read, to create the properties keys on the > > strings, which are then reused. > > I actually do see that. At first I didn't pay much attention to such > outliers. They usually look like the second measurement here: > > Elapsed time: 0.541624s (0.164396s in 5 GCs) > Elapsed time: 0.861175s (0.415142s in 10 GCs) > Elapsed time: 0.486012s (0.057915s in 1 GCs) > Elapsed time: 0.505339s (0.055759s in 1 GCs) > Elapsed time: 0.481024s (0.057757s in 1 GCs) > Elapsed time: 0.471350s (0.056383s in 1 GCs) > Elapsed time: 0.495125s (0.056129s in 1 GCs) > Elapsed time: 0.513310s (0.058437s in 1 GCs) > Elapsed time: 0.491978s (0.057144s in 1 GCs) > > Which keys are those? I only know about one key - 'completion-score'. Yes, that's the one. I suppose adding this key to the property lists of large number of strings, which is only done once, is what's causing the anomaly. > > > This cost is ammortized very quickly, > > of course, but if you're taking the measurement immediately after Emacs > > -Q and with few samples, it skews the numbers. > > I always took around 16 samples, and now made sure to take exactly that > number, starting with "y" and then "yo", "y", etc. Although the timing > for the empty input is usually included (but it doesn't look too > different from the rest). > > Anyway, I retook the numbers a couple of times. One of the patches (the > same one) still looks a little faster, but the fluctuations between runs > are large enough to avoid making any big conclusions: As did I, and I get the same results I posted :-/ > > I think further optimization would be localized to the scoring function > > itself, not to the place where it is performed. > > Most likely, yes. It seems to be the most expensive part. But it still > seems easier to measure/tweak when it happens during a separate step, > rather than mixed in with the rest of completion-all-completions' busines= s. > > >> But if course it would be nice to avoid the wart, so if you have any > >> better ideas, they are welcome. > > > > I'm not saying it would necessarily spread even further, but if you wan= t > > to do scoring "just in time" like I suggested -- presumably to > > completely avoid propertizing strings -- that particular wart spreads a > > little more and thus becomes something that is slightly harder to remov= e > > later on. > > Could you describe the other places you think it might spread to? Other > completion styles like Orderless? Maybe, I don't know. But here I just meant that to do that idea it spreads only one further degree. I'm not saying it would necessarily spread even further. > > As long as there's only one place producing this property (as opposed to > consuming it), it seems straightforward enough to remove anyway. > > >> So far you advocated toward avoiding breaking changes while > >> implementing the present performance improvement. > > > > Both patches do that, so what I've been arguing for is simplicity and > > coherence. I don't think completion-sorted-completions and the > > complexity it brings to minibuffer.el is a step in the rigth direction, > > and the performance benefits it does undeniably bring can be achieved > > with less drastic means. > > What I meant is, solving the quote-unquote conundrum might require a > larger breaking change than the one that you wanted for this discussion. A larger change sure, not sure if "breaking" though. > Anyway, have you looked into what it would take to solve it? No, naively, I just think it's a similar situation of display and business logic being mixed up. Presumably the quoted stuff is just for insertion (and display?), and the unquoted stuff is what patterns/scoring should operate on. But, IMO, there's no need to tackle it right now. If the thing holding you back from the lazy-hilit-2023-v4.patch is the completion-score propertization, I can move it to the sorting step in a future v5 and add spread the completion--unquoted thing a little bit more. Jo=C3=A3o