GNU bug report logs - #48841
fido-mode is slower than ido-mode with similar settings

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>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>, monnier <at> iro.umontreal.ca, 48841 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, larsi <at> gnus.org, 47711 <at> debbugs.gnu.org
Subject: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting
Date: Mon, 16 Aug 2021 17:33:20 +0300

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.

Previous Next

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