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

Previous Next

Full log

Message #296 received at 47711 <at> debbugs.gnu.org (full text, mbox):

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: Re: 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:14:45 +0100

On Fri, Oct 27, 2023 at 12:44 AM João Távora <joaotavora <at> gmail.com> wrote:

> > It is slower in the sorting step, though: mostly due to the extra
> > consing created with the alist to-be-sorted, I guess, but also because
> > of the repeated string-match call (which, while fast and much faster
> > than the match-data call, is still not free).
>
> And is the sorting step not included in the full call to
> completion-filter-completions?  I don't fully understand how it works.

I get it now.  Neither completion-sorted-completions
or completion-all-completions do the sorting.  It's just that
if sorting is bound to be required, completion-all-completions
will do most of the work upfront, and thus sorting will be much
faster in that case, compensating completely.

So now I don't think that micro-benchmark is of much use.  A useful
such benchmark would have to be representative of the full cycle.
Maybe we don't even need this benchmark, given the instrumentation
in icomplete.el works well and seems precise and deterministic (just
not as convenient to run).

João

Previous Next

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