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

[Eli Zaretskii <eliz@gnu.org>]

> Cc: joaotavora@gmail.com, 48841@debbugs.gnu.org, dgutov@yandex.ru,
>  larsi@gnus.org, monnier@iro.umontreal.ca, 47711@debbugs.gnu.org
> From: Daniel Mendler <mail@daniel-mendler.de>
> Date: Mon, 16 Aug 2021 14:49:45 +0200
> 
> On 8/16/21 2:39 PM, Eli Zaretskii wrote:
> >> João, I am giving hard examples here. What is not an example about
> >> "memory leak" or making debugging output verbose thanks to the attached
> >> string properties?
> > 
> > FWIW, I also don't understand how adding properties could cause a
> > memory leak.  When a string is GCed, its properties get GCed as well,
> > all of them.  Am I missing something?
> 
> If you add string properties to all symbol names this memory will stay
> alive for much longer than necessary.

That's a very extreme example, something that I wouldn't expect a Lisp
program to do, without removing the properties shortly thereafter.
And even that isn't a leak.

Note that we already put all kind of properties (although not text
properties) on symbols.

> > As to more difficult debugging, I think adding a couple of properties
> > that have simple structure will not impair debugging too much.
> > Strings with many properties are not uncommon in Emacs, so we already
> > have to deal with that.
> 
> I disagree with that. We are talking about adding string properties to
> every symbol name. This is a global side effect and different from
> adding string properties to a set of isolated string in a controlled
> manner. I also don't understand why one would even want to take any
> chances here given that the feature can be implemented in a way which
> avoids this global side effect entirely as my patch shows.

I understand your aversion from such global effects, but I was talking
specifically about the debugging difficulties.

> > I would indeed suggest both to make sure there's no performance
> > regressions, and would like to see some data similar to what João
> > presented, which backs up your assessments about your proposal being
> > faster.  Since performance is the main motivation for these changes, I
> > think it's important for us to be on the same page wrt facts related
> > to performance, before we make the decision how to proceed.
> 
> I will prepare some benchmarks.

Thank you.