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

[Dmitry Gutov]

On 16.08.2021 17:20, João Távora wrote:

> > > > > 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 that *will* happen with Joao's approach, as soon as some package
> > implements a Lisp completion backend in a certain (legal) fashion.
>
> There is no leak, not in the strong or weak sense.

Eli already said that, in a sentence that I also quoted. And still: "I 
wouldn't expect a Lisp program to do <so>".

> There is a constant
> usage memory footprint proportional to the size of obarray, yes, but the
> factor isn't huge.  From the top of my head, I think it's about two
> conses and a fp number for each sym. does anyone know how much that is
> or can teach me how to measure?  Thanks.

If we say that your approach is legal, those are only "two conses and a 
number" coming from minibuffer.el. But since other packages will also be 
allowed to do that, the factor will only be limited by the amount of 
installed packages.

> Anyway the current situation is constant copies of strings that put
> pressure on the GC, as the benchmarks show.
>
> Anyhoo, in the interest of placating this string property bogeyman, I've
> prepared a version of my patch that is based on weak-keyed hash tables.
> Slightly slower, but not much. Here are the usual benchmarks:

Cool, I'll take a look, thanks.
> > > And even that isn't a leak.
> > > Note that we already put all kind of properties (although not text
> > > properties) on symbols.
> >
> > Those do not, generally, change over time.
>
> Neither does this one! At least in size, which is the thing that
> matters.  So in terms of "negative" consequences it's exactly
> equivalent. Read the patch it will be obvious, I think.

I was talking about the values of the properties, not the size in memory.