Subject: bug#48841: closed (Re: bug#48841: [PATCH] Make fido-mode about as fast as ido-mode even with many completions)

From: [email-masked] (GNU bug Tracking System)
Date: Wed, 25 Aug 2021 15:44:02 +0000

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 [email-masked].

-- 
48841: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=48841
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#48841: [PATCH] Make fido-mode about as fast as ido-mode even with many completions
From: João Távora <[email-masked]>
To: Dmitry Gutov <[email-masked]>
Cc: Daniel Mendler <[email-masked]>, [email-masked], Stefan Monnier <[email-masked]>, [email-masked]
Date: Wed, 25 Aug 2021 16:42:54 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

João Távora <[email-masked]> 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 <[email-masked]> 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

Subject: fido-mode is slower than ido-mode with similar settings
From: Dmitry Gutov <[email-masked]>
To: [email-masked]
Date: Sat, 5 Jun 2021 04:39:49 +0300
List-Id: <debbugs-submit.debbugs.gnu.org>

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.