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


Message #86 received at 48841 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: João Távora <joaotavora <at> gmail.com>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 48841 <at> debbugs.gnu.org
Subject: Re: bug#48841: fido-mode is slower than ido-mode with similar settings
Date: Mon, 14 Jun 2021 03:08:13 +0300
On 13.06.2021 17:29, João Távora wrote:

> Yeah, to be honest, once I'm done actually using these functions I
> immediately evict the differences between try-completion,
> completion-try-completion, try-try-completion-completion, or any of
> these yoda-speak variations from my mental cache.
> 
> Here I meant is that there was something apparently useless and slow (to
> fido-mode at least) going on in that else branch.

And there it was!

>> Elapsed time: 0.329006s (0.246073s in 10 GCs)
>>
>> vs
>>
>> Elapsed time: 0.169200s (0.113762s in 5 GCs)
>>
>> I suppose the 40-70ms difference is due to delay in typing.
> 
> No idea.  In my (slower?) system, I typed C-u C-x C-e C-m pretty fast.
> Presumably the C-m goes in before pp-eval-last-sexp has a chance to read
> more input so I wouldn't think it's a delay in typing.

Some input latency must be there, of course it depends on how fast Emacs 
is handling the previous events, how fast the machine is, etc.

Anyway, I was just describing an easier way to benchmark the same effect 
(without having to hit the key sequence very quickly). Hope you or 
someone else find it useful.

> I could
> investigate, but since your measurements confirm the same tendency
> anyway, I think this simple patch is what's needed to close this issue.

Haven't tested it myself, but it looks like it will almost certainly work.

> diff --git a/lisp/icomplete.el b/lisp/icomplete.el
> index 08b4ef2030..5d37f47e7d 100644
> --- a/lisp/icomplete.el
> +++ b/lisp/icomplete.el
> @@ -859,13 +859,14 @@ icomplete-completions
>                  (base-size (prog1 (cdr last)
>                               (if last (setcdr last nil))))
>                  (most-try
> -                (if (and base-size (> base-size 0))
> -                    (completion-try-completion
> -                     name candidates predicate (length name) md)
> -                  ;; If the `comps' are 0-based, the result should be
> -                  ;; the same with `comps'.
> -                  (completion-try-completion
> -                   name comps nil (length name) md)))
> +                (and (not fido-mode) ; Fido avoids these expensive calculations.

Perhaps predicate it on the value of icomplete-hide-common-prefix instead?

fido-mode sets it to nil, and this way we retain a better level of 
abstraction, and better backward compatibility for vanilla 
icomplete-mode users.

Next step might be switching this var's default value to nil.




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.