bug#48841: closed (fido-mode is slower than ido-mode with similar settings)

[GNU bug Tracking System]

Your message dated Wed, 25 Aug 2021 16:42:54 +0100
with message-id <874kbda5tt.fsf@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@gnu.org.)


-- 
48841: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=48841
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
> --- Begin Message ---
>
>
>
> Subject: 
>
> fido-mode is slower than ido-mode with similar settings
>
>
>
>
> Date: 
>
> Sat, 5 Jun 2021 04:39:49 +0300
>
>
>
>
> User-agent: 
>
> Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1
>
>
>
>
> 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.
>
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> 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
>
>
>
>
> User-agent: 
>
> Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
>
>
>
>
> João Távora <joaotavora@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@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
>
>
>
> --- End Message ---