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: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Dmitry Gutov <dgutov <at> yandex.ru>
Subject: bug#48841: closed (Re: bug#48841: [PATCH] Make fido-mode about as
 fast as ido-mode even with many completions)
Date: Wed, 25 Aug 2021 15:44:02 +0000
[Message part 1 (text/plain, inline)]
Your bug report

#48841: fido-mode is slower than ido-mode with similar settings

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 48841 <at> debbugs.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: 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


[Message part 3 (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.



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.