GNU bug report logs - #47711
27.1; Deferred highlighting support in `completion-all-completions', `vertico--all-completions`

Previous Next

Full log

View this message in rfc822 format

From: João Távora <joaotavora <at> gmail.com>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>, Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>, 47711 <at> debbugs.gnu.org
Subject: bug#47711: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting
Date: Fri, 27 Oct 2023 01:26:53 +0100

On Fri, Oct 27, 2023 at 1:11 AM Dmitry Gutov <dmitry <at> gutov.dev> wrote:

> > Also in the last iteration of the "yoyo" fido-vertical-mode test,
> > results with my latest patch are quite a bit faster.
>
> Hmm, your latest (lazy-hilit-2023-v3.diff) improves the (completing-read
> "" obarray) scenario a lot (over the original two 2023 solutions), but
> not the the 'C-h v' scenario. I don't have an explanation.

The improvement was due to running string-match only once per completion,
if you look at the changes to completion-pcm--all-completions.

It could be this code doesn't kick in in the C-h v scenario.  Notice
that that function already has some optimizations: for example, when
the regexp match is performed by all-completions and its use of
completion-regexp-alist, there's no way to get the regex match data
to compute the score, so it'll have to be postponed to
completion-pcm--hilit-commonality as in the v2.diff case.

Then again, that doesn't explain why in the C-h v scenario, the regression
was fixed precisely by adjust that code that I was conjecturing might
not kick in.

Anyway, I think it's safer to say that my latest patch is at least as fast,
sometimes faster, than the 2023 completion-filter-completions solution.

João

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.