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: Dmitry Gutov <dgutov <at> yandex.ru>
To: João Távora <joaotavora <at> gmail.com>, Daniel Mendler <mail <at> daniel-mendler.de>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 48841 <at> debbugs.gnu.org, 47711 <at> debbugs.gnu.org
Subject: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting
Date: Sat, 14 Aug 2021 05:55:17 +0300

Aside from the mutability/ownership issue,

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.

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.

Previous Next

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