From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Mendler Newsgroups: gmane.emacs.bugs Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Date: Fri, 13 Aug 2021 13:21:32 +0200 Message-ID: <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9315"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 47711@debbugs.gnu.org, Stefan Monnier , 48841@debbugs.gnu.org, Dmitry Gutov To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Aug 13 13:22: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 1mEVGM-00027v-J4 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 13 Aug 2021 13:22:10 +0200 Original-Received: from localhost ([::1]:42110 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mEVGL-00013V-2T for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 13 Aug 2021 07:22:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51588) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mEVGE-00013M-Vt for bug-gnu-emacs@gnu.org; Fri, 13 Aug 2021 07:22:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57299) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mEVGE-0001KW-PP for bug-gnu-emacs@gnu.org; Fri, 13 Aug 2021 07:22:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mEVGE-0004DF-M5 for bug-gnu-emacs@gnu.org; Fri, 13 Aug 2021 07:22:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Mendler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Aug 2021 11:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs Original-Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162885370316128 (code B ref 48841); Fri, 13 Aug 2021 11:22:02 +0000 Original-Received: (at 48841) by debbugs.gnu.org; 13 Aug 2021 11:21:43 +0000 Original-Received: from localhost ([127.0.0.1]:40603 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEVFu-0004C3-K5 for submit@debbugs.gnu.org; Fri, 13 Aug 2021 07:21:42 -0400 Original-Received: from server.qxqx.de ([178.63.65.180]:58693 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEVFs-0004Bk-QI; Fri, 13 Aug 2021 07:21:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=8hwFNV/aAe3vVUeLSmkDH/7Bo2a4jUM3hyldTTf1mXU=; b=Z0MtMaK/toFejKLtw4dwCcoPv3 YNf2RJn82xqwC1SZfFohhyetqlPs/IpcFa3HdDwI5YKS+gW480ebGSmW/RKlFSpKr28QVEAgSI7l0 N4x0J9Nv6N7kXDletNpixpVp6ik9P4RYvzuI/yqa79S6KsPlVCLjehZWNnB0PA5aAHmA=; In-Reply-To: Content-Language: en-US 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:211731 Archived-At: On 8/13/21 12:56 PM, João Távora wrote: > I've read the discussion and am indeed aware of some non-neglibile > performance problems in the flex and pcm completion styles since > they need to copy strings around. Other -- completely different -- > performance problems affect fido-mode specifically (but not > fido-vertical-mode, curiously). > > In some conversation with Dmitry > > bug#48841: fido-mode is slower than ido-mode with similar settings > > We discussed this. I've read the discussion. You are probably aware of my efforts to in Vertico to implement deferred highlighting. The patch I implemented here implements the deferred highlighting in a clean way. > There was also talk of removing the string copying with minimal (but not null) > backward compatibility breakage. I recall Dmitry saying it was easy > to fix on the > completion frontend side. Many such frontends live in Emacs or GNU Elpa. > On the other hand, the patch that we (or at least I) envisioned in > that discussion > was almost certainly much, much simpler than the one being presented here, > and thus much easier to reason about and discuss. No, this is not the case. There is no simple fix of the allocation issue on the frontend side. The existing API `completion-all-completions` necessarily has to allocate all the strings in order to attach highlighting and scoring. The new API solves this in a clean way by both deferring highlighting and scoring. I claim that my patch is easy to reason about and refactors the existing code to address the exact problem we are having. Please take some time in reviewing it. > But to avoid comparing apples to oranges, I would you to summarize exactly, > perhaps in the forms of code snippets, and/or benchmarks exactly what problems > your large patch solves. State the problem(s) first, then the solution > (to each). The main problem is that `completion-all-completions` allocates all the strings every time the completions are filtered. This is the same performance issue you encountered in fido-mode/icomplete-mode. The second problem addressed by the new API `completion-filter-completions` is that `completion-all-completions` is limited in what it can return. For example it cannot return the end position of the completion. This is also solved by the new API. The new API is a clean extensible way forward. Daniel