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

Previous Next

Package: emacs;

Reported by: Dmitry Gutov <dgutov <at> yandex.ru>

Date: Sat, 5 Jun 2021 01:40:01 UTC

Severity: normal

Done: João Távora <joaotavora <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: João Távora <joaotavora <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 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: Thu, 17 Jun 2021 22:21:55 +0100
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.

>>> 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?

>>     ;; 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.

João




This bug report was last modified 3 years and 350 days ago.

Previous Next


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