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

Previous Next

Package: emacs;

Reported by: Daniel Mendler <mail <at> daniel-mendler.de>

Date: Sun, 11 Apr 2021 20:52:01 UTC

Severity: normal

Found in version 27.1

Done: Daniel Mendler <mail <at> daniel-mendler.de>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

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




This bug report was last modified 172 days ago.

Previous Next


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