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>, Stefan Monnier <monnier <at> iro.umontreal.ca>, 48841 <at> debbugs.gnu.org
Subject: bug#48841: fido-mode is slower than ido-mode with similar settings
Date: Sun, 4 Jul 2021 04:53:07 +0300

On 18.06.2021 00:21, João Távora wrote:
> Dmitry Gutov <dgutov <at> yandex.ru> writes:
> 
>>>> I disagree it's a simpler technique, but it would indeed be a simpler
>>>> change, based on the current implementation.
>>> simpler means simpler in my book :-)
>>
>> One is simpler diff, another is simpler resulting code. Both have
>> their upsides.
> 
> Oh, you meant the The Big Redesign?  I'm a fan of that too, not only
> here but constantly, everywhere...  That indeed means simpler resulting
> code in abstract.  Problem is that also means different resulting code
> to different people.  But is definitely doable.

I meant a particular change (not modifying the strings at all in 
advance) which would be bigger and indeed might better fit The Big Redesign.

>>>> But I don't mind it myself, and happy to update Company. Either way
>>>> it's a step forward.
>>> If Company and fido-mode and a couple more outside the core/Elpa are
>>> all
>>> that's needed, it's probably warranted.  But there are so many frontends
>>> right now, I don't know...  We'd need some "opt into the optimization",
>>> I think."
>>
>> Since all other users are third-party (and thus have short release
>> cycles), it shouldn't be too much of a problem. Some highlighting code
>> would start to fail, but probably without disastrous results. And then
>> people will issue updates to look for some new property when the old
>> expected ones are all missing.
> 
> OK.  I can live with that rationale.  So what are the places to touch
> that "we" control?
> 
> - icomplete.el? for fido-mode & friends
> - minibuffer.el, for the *Completions* buffer
> - company.el
> - Any notable others?

corfu, consult, etc? Probably Ivy too. All of these are in GNU ELPA.

BTW, I think Daniel had some ideas about applying the face property 
lazily as well. I can't find the particular discussion now, but perhaps 
he can add to this discussion as well.

>>>      ;; with copy
>>>      (2.869362171 6 2.3882547280000495)
>>>      (2.909661303 6 2.4209153659999743)
>>>      (2.845522439 6 2.3638140250000106)
>>>           ;; without copy.  Huge speedup.
>>>      (0.79817337 1 0.4526993239999797)
>>>      (0.8231736510000001 1 0.4752496449999626)
>>>      (0.719004478 1 0.4016016420000028)
>>
>> Even better.
>>
>> My current session has 37559 symbols, so it's somewhere in the middle.
> 
> Yes, this is a big performance bottleneck.  But i wonder if tweaking GC
> parameter would help here.  I know nothing of Emacs GC parameters.

I think the current understanding that by raising gc-cons-threshold we 
exchange the number of GC pauses for larger latencies. I suppose one 
could tune that value to a particular workload such that the 4 GCs in a 
row that I had will turn into just one (and thus save on re-scanning the 
heap 3 times), but data sets change.

Previous Next

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