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

[Eli Zaretskii <eliz@gnu.org>]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 14 Aug 2021 05:55:17 +0300
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 48841@debbugs.gnu.org,
>  47711@debbugs.gnu.org
> 
> On 13.08.2021 15:05, João Távora wrote:
> > If one removes these lines, the process becomes much faster, but there is a
> > problem with highlighting.  My idea is indeed to defer highlighting by not
> > setting the 'face property directly on that shared string, but some
> > other property
> > that is read later from the shared string by compliant frontents.
> 
> I haven't done any direct benchmarking, but I'm pretty sure that this 
> approach cannot, by definition, be as fast as the non-mutating one.

Daniel seems to think otherwise, AFAIU.

> Because you go through the whole list and mutate all of its elements, 
> you have to perform a certain bit of work W x N times, where N is the 
> size of the whole list.
> 
> Whereas the deferred-mutation approach will only have to do its bit 
> (which is likely more work, like, WWW) only 20 times, or 100 times, or 
> however many completions are displayed. And this is usually negligible.
> 
> However big the difference is going to be, I can't say in advance, of 
> course, or whether it's going to be shadowed by some other performance 
> costs. But the non-mutating approach should have the best optimization 
> potential when the list is long.

So I guess the suggestion to have a benchmark is still useful, because
the estimations of which approach has better performance vary between
you three.  So maybe producing such benchmarks would be a good step?