[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#48841: fido-mode is slower than ido-mode with similar settings
From: |
Dmitry Gutov |
Subject: |
bug#48841: fido-mode is slower than ido-mode with similar settings |
Date: |
Sat, 12 Jun 2021 03:43:43 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 |
On 12.06.2021 02:24, João Távora wrote:
Dmitry Gutov <dgutov@yandex.ru> writes:
Looking forward for your analysis of fido-vertical-mode's performance
improvement over the "normal" one.
So, I benchmarked before and after this patch to icomplete.el:
diff --git a/lisp/icomplete.el b/lisp/icomplete.el
index 08b4ef2030..3561ebfa04 100644
--- a/lisp/icomplete.el
+++ b/lisp/icomplete.el
@@ -858,16 +858,8 @@ icomplete-completions
;; removing making `comps' a proper list.
(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)))
- (most (if (consp most-try) (car most-try)
- (if most-try (car comps) "")))
+ (most-try nil)
+ (most "")
;; Compare name and most, so we can determine if name is
;; a prefix of most, or something else.
(compare (compare-strings name nil nil
All right, so this is not about try-completion, it's about
completion-try-completion. That makes sense.
The patch itself nullifies the calculation of the 'determ' thing that I
and presumably some other users don't value that much. It doesn't
affect fido-mode's basic funcionality.
How did I benchmark? Well, to measure the delay the user experiences
until all completions are presented I had to take out the
`while-no-input` in icomplete-exhibit so that this test would work:
;; After the form, type C-u C-x C-e C-m in quick succession
(benchmark-run (completing-read "bla" obarray))
If I don't remove this `while-no-input`, icomplete will not lose time
showing all the completions and will instead select just the first one.
That's a very nice feature for actual use, but for this benchmark that
is not what I want: I want to measure the time to show all the
completions.
Did the same, can repro.
Then, the times presented by benchmark-run are the same that the user
sees if he waits to see the completions. Now the values:
Before my patch:
(1.802209488 5 1.3678843490000077)
(1.609066281 4 1.1170432569999775)
(1.878972079 5 1.3725165670000479)
(1.901952581 5 1.3979494059999524)
(1.820800064 5 1.3283940110000003)
After the patch:
(0.552051921 1 0.3079724459999511)
(0.58396499 1 0.3038616050000087)
(0.861106587 2 0.6046198220000178)
(0.611551175 1 0.30275532399997473)
(0.62500199 1 0.3160454470000218)
I get
(0.377195885 10 0.24448539800000013)
before and
(0.245218061 6 0.1390041310000001)
after. A solid improvement.
BTW, if I just stick benchmark-progn around icomplete-completions like
diff --git a/lisp/icomplete.el b/lisp/icomplete.el
index 08b4ef2030..b9fe3e1836 100644
--- a/lisp/icomplete.el
+++ b/lisp/icomplete.el
@@ -678,12 +678,13 @@ icomplete-exhibit
;; seems to trigger it fairly often!
(while-no-input-ignore-events '(selection-request))
(text (while-no-input
- (icomplete-completions
- field-string
- (icomplete--completion-table)
- (icomplete--completion-predicate)
- (if (window-minibuffer-p)
- (eq minibuffer--require-match t)))))
+ (benchmark-progn
+ (icomplete-completions
+ field-string
+ (icomplete--completion-table)
+ (icomplete--completion-predicate)
+ (if (window-minibuffer-p)
+ (eq minibuffer--require-match t))))))
(buffer-undo-list t)
deactivate-mark)
;; Do nothing if while-no-input was aborted.
...it reports
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.
- bug#48841: fido-mode is slower than ido-mode with similar settings, (continued)
- bug#48841: fido-mode is slower than ido-mode with similar settings, Dmitry Gutov, 2021/06/06
- bug#48841: fido-mode is slower than ido-mode with similar settings, João Távora, 2021/06/07
- bug#48841: fido-mode is slower than ido-mode with similar settings, Dmitry Gutov, 2021/06/10
- bug#48841: fido-mode is slower than ido-mode with similar settings, João Távora, 2021/06/11
- bug#48841: fido-mode is slower than ido-mode with similar settings, Dmitry Gutov, 2021/06/11
- bug#48841: fido-mode is slower than ido-mode with similar settings, Dmitry Gutov, 2021/06/11
- bug#48841: fido-mode is slower than ido-mode with similar settings, João Távora, 2021/06/13
- bug#48841: fido-mode is slower than ido-mode with similar settings, Dmitry Gutov, 2021/06/16
- bug#48841: fido-mode is slower than ido-mode with similar settings, João Távora, 2021/06/17
- bug#48841: fido-mode is slower than ido-mode with similar settings, João Távora, 2021/06/11
- bug#48841: fido-mode is slower than ido-mode with similar settings,
Dmitry Gutov <=
- bug#48841: fido-mode is slower than ido-mode with similar settings, João Távora, 2021/06/13
- bug#48841: fido-mode is slower than ido-mode with similar settings, Dmitry Gutov, 2021/06/13
- bug#48841: fido-mode is slower than ido-mode with similar settings, João Távora, 2021/06/13
- bug#48841: fido-mode is slower than ido-mode with similar settings, Dmitry Gutov, 2021/06/16
- bug#48841: fido-mode is slower than ido-mode with similar settings, João Távora, 2021/06/17
- bug#48841: fido-mode is slower than ido-mode with similar settings, Stefan Monnier, 2021/06/05
- bug#48841: fido-mode is slower than ido-mode with similar settings, João Távora, 2021/06/06
- bug#48841: fido-mode is slower than ido-mode with similar settings, Dmitry Gutov, 2021/06/06
- bug#48841: fido-mode is slower than ido-mode with similar settings, João Távora, 2021/06/06
- bug#48841: fido-mode is slower than ido-mode with similar settings, Dmitry Gutov, 2021/06/06