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

Previous Next

Full log

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: João Távora <joaotavora <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>, Eli Zaretskii <eliz <at> gnu.org>,
 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 02:10:48 +0300

Hi Joao,

Thanks for the updates and the numbers.

On 27/10/2023 00:49, João Távora wrote:
> João Távora<joaotavora <at> gmail.com>  writes:
> 
>> So, backed by the new ability to conduct good benchmarks, I looked at
>> the problem anew. I found some insight in the problem, and came up with
>> a new "lazy-hilit" patch which performs just as well, if not slightly
>> better, than Daniel's, while keeping the changes to lisp/minibuffer.el
>> much more minimal and not adding replacement for the longstanding
>> completion-all-completions.
> Working on this a bit more, I've now been able to optimize the "lazy
> hilit" patch even further by recognizing that in many situations we
> don't need to match the "PCM" pattern to each string twice.  The first
> time we do it, we can calculate a score immediately and store it in the
> string.  The average response times for the "yo-yoo" test described
> previously:

This latest change in particular regressed this related scenario:

;; Use 'set' to ensure that the variables are bound.
(cl-loop repeat 300000 do (set (intern (symbol-name (gensym "yoyo"))) 4))

C-h v <then type y o <backspace> o <backspace> ...>

It increased the timings for that scenario from ~0.600s (with either of 
the latest filter-deferred patches and your previous version) to ~1s.

My understanding is it's due to the judicious call (copy-sequence orig) 
that you added before 'put-text-property' is called. While it seems like 
a good idea to preserve the original value, when almost all of obarray 
matches the current input (which is the current scenario), a lot of 
strings will be copied.

But (completing-read "" obarray) is not affected, and I don't see why. 
Maybe because it re-sorts less than icomplete? And the consing triggers 
the GC threshold less often (thanks to the other changes).

Previous Next

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