bug#47711: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting

[Dmitry Gutov]

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@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).