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: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: João Távora <joaotavora <at> gmail.com>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#48841: closed (fido-mode is slower than ido-mode with similar
 settings)
Date: Wed, 25 Aug 2021 15:44:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Wed, 25 Aug 2021 16:42:54 +0100
with message-id <874kbda5tt.fsf <at> gmail.com>
and subject line Re: bug#48841: [PATCH] Make fido-mode about as fast as ido-mode even with many completions
has caused the debbugs.gnu.org bug report #48841,
regarding fido-mode is slower than ido-mode with similar settings
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
48841: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=48841
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: bug-gnu-emacs <at> gnu.org
Subject: fido-mode is slower than ido-mode with similar settings
Date: Sat, 5 Jun 2021 04:39:49 +0300

I'm comparing

  ido-mode
  with ido-ubiquitous-mode (for support for arbitrary completion 
tables), available at 
https://github.com/DarwinAwardWinner/ido-completing-read-plus
  with (setq ido-enable-flex-matching t), of course

versus

 fido-mode
 with
   (setq icomplete-compute-delay 0)
   (setq icomplete-show-matches-on-no-input t)
   (setq icomplete-max-delay-chars 0)

The values chosen for behavior maximally close to ido.

Try something like:

 - Start a session with personal config and a number of loaded packages 
(so that there are a lot of functions defined in obarray)
 - Type 'C-h f'
 - Type 'a', then type 'b'.
 - Delete 'b', type it again, see how quickly you can make the 
completions update.

With ido, the updates seem instant (probably due to some magic in 
ido-completing-read-plus); with fido, there is some lag. Not huge, but 
easy enough to notice.

[Message part 3 (message/rfc822, inline)]

From: João Távora <joaotavora <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>, eliz <at> gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, 48841-done <at> debbugs.gnu.org
Subject: Re: bug#48841: [PATCH] Make fido-mode about as fast as ido-mode
 even with many completions
Date: Wed, 25 Aug 2021 16:42:54 +0100

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

> [I've removed bug#47711 from the list, since I haven't read the bug.
> This is only directly concerned with this report bug#48841 about speed
> differences between fido-mode and ido-mode.]
>
> João Távora <joaotavora <at> gmail.com> writes:
>
>> scratch/icomplete-lazy-highlight-attempt-2, although still incomplete,
>> is one such approach, though it still sets `completion-score` on the
>> "shared" string, used later for sorting.  But also that could be
>> prevented (again, only if it turns out to be actually problematic
>> IMO).
>
> I have tested the patch more thoroughly now, and have not found any
> problems.

As I wait for genuine reports or explanations of the much dramatized
problems in the above patch, I've pushed a much simpler patch that has a
dramatic beneficial effect: simply don't do any copying, highlighting or
scoring if the pcm-style pattern (used by the styles 'flex', 'substring'
and others) is empty.

This more than halves the waiting time for the candidate display when
the pattern is empty.  As far as i can tell, `fido-mode` is now faster
than `ido-mode` and so I'm marking this bug closed.

Of course, when there is a pattern of a single character or more, the
icomplete waiting times using my earlier 'completion-lazy-highlight'
patch are still around 70% of the current master.  But those times are
always quite shorter than the empty-pattern case.  I'll wait a bit for
the alternatives presumably being worked on before pushing that or
something based on it.

João

Previous Next

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