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: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Date: Sat, 14 Aug 2021 09:23:25 +0100 Message-ID: <87sfzca0zm.fsf@gmail.com> References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@yandex.ru> 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="31657"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Daniel Mendler , Stefan Monnier , 48841@debbugs.gnu.org, 47711@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Aug 14 10:24:11 2021 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 1mEoxe-000812-G8 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 14 Aug 2021 10:24:10 +0200 Original-Received: from localhost ([::1]:57508 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mEoxc-0004Rd-Mw for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 14 Aug 2021 04:24:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51682) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mEoxW-0004RN-E3 for bug-gnu-emacs@gnu.org; Sat, 14 Aug 2021 04:24:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60197) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mEoxW-0003Ba-7J for bug-gnu-emacs@gnu.org; Sat, 14 Aug 2021 04:24:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mEoxV-0005Oh-Vm for bug-gnu-emacs@gnu.org; Sat, 14 Aug 2021 04:24: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: Sat, 14 Aug 2021 08:24:01 +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.162892942820724 (code B ref 47711); Sat, 14 Aug 2021 08:24:01 +0000 Original-Received: (at 47711) by debbugs.gnu.org; 14 Aug 2021 08:23:48 +0000 Original-Received: from localhost ([127.0.0.1]:43510 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEoxF-0005O3-06 for submit@debbugs.gnu.org; Sat, 14 Aug 2021 04:23:48 -0400 Original-Received: from mail-wr1-f49.google.com ([209.85.221.49]:36492) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEox5-0005NY-7j; Sat, 14 Aug 2021 04:23:39 -0400 Original-Received: by mail-wr1-f49.google.com with SMTP id b13so16406279wrs.3; Sat, 14 Aug 2021 01:23:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=PbE/O458f4w1AgSVDgGeifvLtJWnYHfLvklmc66ifKw=; b=r4GFs6/YIoNbxO9A3AhZshKw8xKPXEi/GCsoOt5lD/zXIZpM4PN5Of0jkm5/MD40LB SMUM7p6C0w6y3voUSs52UydRmLrkM0b5KGQPF3FUkDnmIg8dz9Q3EjiK+jzqsGIKdnN2 ibfngZ3SqmKXAwkybP1fnLcmuKL3bNBfTJBPxRohx+mFHYBTiGCEN4T6wLlujbOkcXqW kZN/waUTySLyUJERyOs8+feDDU4zT6TPvi/usj22Y+rMp8J/m/iydEb9TsqoZUFqPrFm 8kKe7eUrrMtP+uRUyYD8kCwFqsWKQbSX3bufB1YoWRxBonZ+pDRdbFQMBFQEz5izjd3R XyVQ== 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:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=PbE/O458f4w1AgSVDgGeifvLtJWnYHfLvklmc66ifKw=; b=S7Vj7+9BJ0Xy25H7WuASDth3Q6fVU0VMVNO0H+tWZbBELCcTYRuaGfFLbxTZUHCuU+ cGE3kzEKOqFz3NCCcrAwx14U6zW43oszTaqmQc2RJdys6vyv2AGhvy3wuYYYNJzfyyG0 2hXRw/S4+Rrk1OKSS9PHg4WH9ukxZSIPRGajrkd+qzG7Z21IGx7ZxNAkzwfItlYV1XY5 zkecBvBbjqM599sd06u6QoKHGg1pbXvzknk3Vgj+CbhKdCUOKBbG2nr4/EQFmLbJxtzm MYWBtGNuBgamqYXW48LbzKIuk/ulqt262W2ipbHqzM8Cwqy5QDNH+IeYvg/ekYm16Xqz 5/lg== X-Gm-Message-State: AOAM532NYOQFPTnIyonOt0s6zM3IRmISYCtLsvuxCVYvz1izjrnP3Cgt WRfipPNgR6ru+2YMkgQccD9cTAkgFlc= X-Google-Smtp-Source: ABdhPJw13EjCIKhW4B0XX0PCwubNK8eU02A7Jj4+dq420uMlLn626Rrwj8Ocwoi2pBUWwsK9BH6wMg== X-Received: by 2002:adf:d085:: with SMTP id y5mr7301176wrh.209.1628929408907; Sat, 14 Aug 2021 01:23:28 -0700 (PDT) Original-Received: from krug (a94-133-27-132.cpe.netcabo.pt. [94.133.27.132]) by smtp.gmail.com with ESMTPSA id x18sm3687486wmc.17.2021.08.14.01.23.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 14 Aug 2021 01:23:27 -0700 (PDT) In-Reply-To: <328f87eb-6474-1442-e1ca-9ae8deb2a84a@yandex.ru> (Dmitry Gutov's message of "Sat, 14 Aug 2021 05:55:17 +0300") 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" Xref: news.gmane.io gmane.emacs.bugs:211810 Archived-At: Dmitry Gutov writes: > Aside from the mutability/ownership issue, > > On 13.08.2021 15:05, Jo=C3=A3o T=C3=A1vora wrote: >> If one removes these lines, the process becomes much faster, but there i= s a >> problem with highlighting. My idea is indeed to defer highlighting by n= ot >> setting the 'face property directly on that shared string, but some >> other property >> that is read later from the shared string by compliant frontents. > > I haven't done any direct benchmarking, but I'm pretty sure that this > approach cannot, by definition, be as fast as the non-mutating one. > > Because you go through the whole list and mutate all of its elements, > you have to perform a certain bit of work W x N times, where N is the > size of the whole list. Let's call W the work that you perform N times in this istuation. In the non-mutation, let's call it Z. So W <=3D Z, because Z not only propertizes the string with a calculation of faces but _also copies its character contents_. Also I think it's better to start about copying rather than mutating. As Eli points out, putting a text property in a string (my idea) is not equivalent with "mutating" it. > Whereas the deferred-mutation approach will only have to do its bit > (which is likely more work, like, WWW) only 20 times, or 100 times, or > however many completions are displayed. And this is usually > negligible. I think you're going in the same fallacy you went briefly in the other bug report. The flex and pcm styles (meaning completion-pcm--hilit-commonality) has to go through all the completions when deciding the score to atribute to each completion that we already know matches the pattern. That's because this scoring is essential to sorting. That's a given in both scenarios, copying and non-copying. Then, it's true that only a very small set of those eventually have to be displayed to the user, depending on where wants she wants her scrolling page to be. So that's when you have to apply 'face' to, say 20 strings, and that can indeed be pretty fast. But where does the information come from? - Currently, it comes from the string's 'face' itself, which was copied entirely. - In the non-copying approach, it must come from somewhere else. One idea is that it comes from a new "private" property 'lazy-face', also in the string itselv, but which was _not_ copied. Another idea is just to remember the pattern and re-match it to those 20 strings. I think the second alternative is always faster. > However big the difference is going to be, I can't say in advance, of > course, or whether it's going to be shadowed by some other performance > costs. But the non-mutating approach should have the best optimization > potential when the list is long. Don't think so. I'm doing benchmarks, will post soon. Jo=C3=A3o