* why is my cd command on eshell on Windows so slow?
@ 2021-04-16 18:40 Wayne Harris via Users list for the GNU Emacs text editor
2021-04-16 18:59 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Wayne Harris via Users list for the GNU Emacs text editor @ 2021-04-16 18:40 UTC (permalink / raw)
To: help-gnu-emacs
This problem has to do either with eshell on GNU Emacs 27.1 or with
Windows and eshell on GNU Emacs 27.1. I say this because I don't see
the same behavior with eshell on GNU Emacs 24.3. (The cd command on
eshell on GNU Emacs 24.3 is pretty fast.) But let's see what happens on
GNU Emacs 27.1.
Thinking it could somehow be the command itself, I uselessly created
this following alias:
%alias | grep 'cd time'
alias cd time cd $*
%
So when I cd into a directory, I get:
%cd dir/
0.001 secs
%
However, it actually took about 3 seconds for me to get my prompt back.
There is something before cd actually operates (or afterwards) that
makes me wait --- *sometimes*. If I immediately ``cd ..'' and then cd
into dir/ once again, it's pretty fast.
%which cd
eshell/cd is a compiled Lisp function in `em-dirs.el'
%
Can you point me in the right direction? This is a Windows system.
I would love to fix this delay. It is not too infrequent and it is
correlated to directories infrequently acessed. Thank you!
(*) One thing I tried
I tried
(setq w32-get-true-file-attributes nil)
given its documentation (below), but I see no difference. (Notice I
don't set this variable on my GNU Emacs 24.3 and I don't see any slow
down at all.)
--8<---------------cut here---------------start------------->8---
w32-get-true-file-attributes is a variable defined in ‘C source code’.
Its value is nil
Documentation:
Non-nil means determine accurate file attributes in ‘file-attributes’.
This option controls whether to issue additional system calls to determine
accurate link counts, file type, and ownership information. It is more
useful for files on NTFS volumes, where hard links and file security are
supported, than on volumes of the FAT family.
Without these system calls, link count will always be reported as 1 and file
ownership will be attributed to the current user.
The default value ‘local’ means only issue these system calls for files
on local fixed drives. A value of nil means never issue them.
Any other non-nil value means do this even on remote and removable drives
where the performance impact may be noticeable even on modern hardware.
--8<---------------cut here---------------end--------------->8---
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: why is my cd command on eshell on Windows so slow?
2021-04-16 18:40 why is my cd command on eshell on Windows so slow? Wayne Harris via Users list for the GNU Emacs text editor
@ 2021-04-16 18:59 ` Eli Zaretskii
2021-04-16 20:14 ` Wayne Harris via Users list for the GNU Emacs text editor
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2021-04-16 18:59 UTC (permalink / raw)
To: help-gnu-emacs
> Date: Fri, 16 Apr 2021 15:40:29 -0300
> From: Wayne Harris via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
>
> So when I cd into a directory, I get:
>
> %cd dir/
> 0.001 secs
> %
>
> However, it actually took about 3 seconds for me to get my prompt back.
> There is something before cd actually operates (or afterwards) that
> makes me wait --- *sometimes*. If I immediately ``cd ..'' and then cd
> into dir/ once again, it's pretty fast.
>
> %which cd
> eshell/cd is a compiled Lisp function in `em-dirs.el'
> %
>
> Can you point me in the right direction? This is a Windows system.
Profile it, then look at the profile to see what takes most of the
time.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: why is my cd command on eshell on Windows so slow?
2021-04-16 18:59 ` Eli Zaretskii
@ 2021-04-16 20:14 ` Wayne Harris via Users list for the GNU Emacs text editor
2021-04-16 21:14 ` Stefan Monnier
0 siblings, 1 reply; 12+ messages in thread
From: Wayne Harris via Users list for the GNU Emacs text editor @ 2021-04-16 20:14 UTC (permalink / raw)
To: help-gnu-emacs
Eli Zaretskii <eliz@gnu.org> writes:
>> Date: Fri, 16 Apr 2021 15:40:29 -0300
>> From: Wayne Harris via Users list for the GNU Emacs text editor
>> <help-gnu-emacs@gnu.org>
>>
>> So when I cd into a directory, I get:
>>
>> %cd dir/
>> 0.001 secs
>> %
>>
>> However, it actually took about 3 seconds for me to get my prompt back.
>> There is something before cd actually operates (or afterwards) that
>> makes me wait --- *sometimes*. If I immediately ``cd ..'' and then cd
>> into dir/ once again, it's pretty fast.
>>
>> %which cd
>> eshell/cd is a compiled Lisp function in `em-dirs.el'
>> %
>>
>> Can you point me in the right direction? This is a Windows system.
>
> Profile it, then look at the profile to see what takes most of the
> time.
Thank you. Didn't know there was a profiler. I'm not sure I know how
to use it. The output is below, but before I will summarize what I
found with the profiler.
(*) Summary of findings
It appears that the delay has nothing to do with Windows or with the
cd-command. It seems to be the procedure
completion-in-region--postch
from minibuffer.el. To certify, I commented out all the code in this
procedure and tried various commands, then uncommented it again and saw
more delays, so it seems reproducible.
In the next sections I describe what I did in chronological order that
has led me to this observation.
(*) What I did
I prepared a ``cd some-dir/'' on eshell --- thinking this directory
would cause a slow down. I was often wrong, so I tried different
directories until I saw a delay. Before issuing the cd-command, I said
M-x profiler-start
then I pressed enter to issue the cd-command. Then I said
M-x profiler-report
M-x profiler-stop.
Looking at the output, it looks like most of the time is spent not in
executing the command. I read it as 72% of the time is spent outside of
command-execute, that is, in completion-in-region--postch.
--8<---------------cut here---------------start------------->8---
- completion-in-region--postch 119 72%
- #<compiled 0x34cb2ad> 119 72%
- pcomplete-completions-at-point 119 72%
- pcomplete-completions 119 72%
- #<compiled 0x254143d> 119 72%
- pcomplete--here 119 72%
- #<compiled 0x2541429> 119 72%
- eshell-complete-commands-list 104 63%
- eshell-winnow-list 1 0%
- eshell-find-alias-function 1 0%
file-name-base 1 0%
- command-execute 40 24%
- call-interactively 40 24%
- funcall-interactively 26 15%
- execute-extended-command 26 15%
- execute-extended-command--shorter 25 15%
- completion-try-completion 24 14%
- completion--nth-completion 24 14%
- completion--some 24 14%
- #<compiled 0x34c8a4d> 24 14%
- completion-pcm-try-completion 16 9%
- completion-pcm--find-all-completions 15 9%
completion-pcm--all-completions 15 9%
completion-pcm--merge-try 1 0%
completion-basic-try-completion 8 4%
- sit-for 1 0%
redisplay 1 0%
- byte-code 14 8%
- read-extended-command 14 8%
- completing-read 14 8%
- completing-read-default 14 8%
- read-from-minibuffer 10 6%
- command-execute 6 3%
- call-interactively 6 3%
- funcall-interactively 6 3%
- minibuffer-complete 6 3%
- completion-in-region 6 3%
- completion--in-region 6 3%
- #<compiled 0x2646831> 6 3%
- apply 6 3%
- #<compiled 0x1013d81> 6 3%
- completion--in-region-1 6 3%
- completion--do-completion 6 3%
- completion-try-completion 4 2%
- completion--nth-completion 4 2%
- completion--some 4 2%
- #<compiled 0x264f8fd> 4 2%
- completion-basic-try-completion 2 1%
- try-completion 2 1%
- #<compiled 0x1046b41> 2 1%
complete-with-action 2 1%
- completion-pcm-try-completion 1 0%
- completion-pcm--find-all-completions 1 0%
- completion-pcm--all-completions 1 0%
- all-completions 1 0%
- #<compiled 0x1046b41> 1 0%
complete-with-action 1 0%
- completion-emacs22-try-completion 1 0%
- try-completion 1 0%
- #<compiled 0x1046b41> 1 0%
complete-with-action 1 0%
- completion--message 2 1%
- minibuffer-message 2 1%
- sit-for 2 1%
redisplay 1 0%
- ... 6 3%
Automatic GC 6 3%
--8<---------------cut here---------------end--------------->8---
The procedure
completion-in-region--postch
belongs to minibuffer.el. Here is its source code.
--8<---------------cut here---------------start------------->8---
;; It is difficult to know when to exit completion-in-region-mode (i.e. hide
;; the *Completions*). Here's how previous packages did it:
;; - lisp-mode: never.
;; - comint: only do it if you hit SPC at the right time.
;; - pcomplete: pop it down on SPC or after some time-delay.
;; - semantic: use a post-command-hook check similar to this one.
(defun completion-in-region--postch ()
(or unread-command-events ;Don't pop down the completions in the middle of
;mouse-drag-region/mouse-set-point.
(and completion-in-region--data
(and (eq (marker-buffer (nth 0 completion-in-region--data))
(current-buffer))
(>= (point) (nth 0 completion-in-region--data))
(<= (point)
(save-excursion
(goto-char (nth 1 completion-in-region--data))
(line-end-position)))
(funcall completion-in-region-mode--predicate)))
(completion-in-region-mode -1)))
--8<---------------cut here---------------end--------------->8---
(*) An attempt at confirming what appears to be
I commented out all the code of this procedure, so calling it should not
delay at all. Indeed, after that I don't see any delay at all and it's
much more pleasant to use eshell. Uncommenting the code does bring back
the delay sometimes. Either I'm terribly unlucky or the performance
penalty here is confirmed.
(*) What I see in GNU Emacs 24.3
It seems a lot simpler.
--8<---------------cut here---------------start------------->8---
- call-interactively 4 66%
- list 4 66%
- read-extended-command 4 66%
- completing-read 4 66%
- completing-read-default 4 66%
- read-from-minibuffer 4 66%
redisplay_internal (C function) 1 16%
redisplay_internal (C function) 2 33%
Automatic GC 0 0%
--8<---------------cut here---------------end--------------->8---
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: why is my cd command on eshell on Windows so slow?
2021-04-16 20:14 ` Wayne Harris via Users list for the GNU Emacs text editor
@ 2021-04-16 21:14 ` Stefan Monnier
2021-04-17 0:10 ` Wayne Harris via Users list for the GNU Emacs text editor
0 siblings, 1 reply; 12+ messages in thread
From: Stefan Monnier @ 2021-04-16 21:14 UTC (permalink / raw)
To: help-gnu-emacs
>>> %cd dir/
>>> 0.001 secs
>>> %
[...]
> It appears that the delay has nothing to do with Windows or with the
> cd-command. It seems to be the procedure
>
> completion-in-region--postch
Sounds like bug#41423.
If that's the case, then I suggest you try the code in Emacs's `master`
where it should be fixed.
Stefan
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: why is my cd command on eshell on Windows so slow?
2021-04-16 21:14 ` Stefan Monnier
@ 2021-04-17 0:10 ` Wayne Harris via Users list for the GNU Emacs text editor
2021-04-17 8:28 ` Wayne Harris via Users list for the GNU Emacs text editor
0 siblings, 1 reply; 12+ messages in thread
From: Wayne Harris via Users list for the GNU Emacs text editor @ 2021-04-17 0:10 UTC (permalink / raw)
To: help-gnu-emacs
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>>> %cd dir/
>>>> 0.001 secs
>>>> %
> [...]
>> It appears that the delay has nothing to do with Windows or with the
>> cd-command. It seems to be the procedure
>>
>> completion-in-region--postch
>
> Sounds like bug#41423.
> If that's the case, then I suggest you try the code in Emacs's `master`
> where it should be fixed.
It really sounds like bug#41423, even because the workaround provided by
Gregory Heytings solves the problem, that is, I don't notice any slow
down after applying:
--8<---------------cut here---------------start------------->8---
(add-hook
'eshell-mode-hook
(function (lambda ()
(setq completion-at-point-functions '(pcomplete t)))))
--8<---------------cut here---------------end--------------->8---
On the other hand, applying your patch...
--8<---------------cut here---------------start------------->8---
diff --git a/lisp/eshell/em-cmpl.el b/lisp/eshell/em-cmpl.el
index faf749d836..744be525ec 100644
--- a/lisp/eshell/em-cmpl.el
+++ b/lisp/eshell/em-cmpl.el
@@ -399,16 +399,21 @@
(defun eshell-complete-commands-list ()
"Generate list of applicable, visible commands."
- (let ((filename (pcomplete-arg)) glob-name)
+ ;; Building the commands list can take quite a while, especially over Tramp
+ ;; (bug#41423), so do it lazily.
+ (let ((glob-name
+ ;; When a command is specified using `eshell-explicit-command-char',
+ ;; that char is not part of the command and hence not part of what
+ ;; we complete. Adjust `pcomplete-stub' accordingly!
+ (if (and (> (length pcomplete-stub) 0)
+ (eq (aref pcomplete-stub 0) eshell-explicit-command-char))
+ (setq pcomplete-stub (substring pcomplete-stub 1)))))
+ (completion-table-dynamic
+ (lambda (filename)
(if (file-name-directory filename)
(if eshell-force-execution
(pcomplete-dirs-or-entries nil #'file-readable-p)
(pcomplete-executables))
- (if (and (> (length filename) 0)
- (eq (aref filename 0) eshell-explicit-command-char))
- (setq filename (substring filename 1)
- pcomplete-stub filename
- glob-name t))
(let* ((paths (eshell-get-path))
(cwd (file-name-as-directory
(expand-file-name default-directory)))
@@ -455,7 +460,7 @@
(and eshell-show-lisp-alternatives
(null completions)))
(all-completions filename obarray #'functionp))
- completions)))))))
+ completions)))))))))
(define-obsolete-function-alias 'eshell-pcomplete #'completion-at-point "27.1")
--8<---------------cut here---------------end--------------->8---
...does not make any noticeable change. Should I try a clean master to
make sure I'm doing the right thing here? Notice my case the slow down
is only involved with local files, no tramp business. I do experience
the ~0.5-second delay mentioned by Tim Vaughan. (Sometimes it takes
longer.)
Thanks!
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: why is my cd command on eshell on Windows so slow?
2021-04-17 0:10 ` Wayne Harris via Users list for the GNU Emacs text editor
@ 2021-04-17 8:28 ` Wayne Harris via Users list for the GNU Emacs text editor
2021-04-17 14:08 ` Stefan Monnier
0 siblings, 1 reply; 12+ messages in thread
From: Wayne Harris via Users list for the GNU Emacs text editor @ 2021-04-17 8:28 UTC (permalink / raw)
To: help-gnu-emacs
Wayne Harris via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>>>> %cd dir/
>>>>> 0.001 secs
>>>>> %
>> [...]
>>> It appears that the delay has nothing to do with Windows or with the
>>> cd-command. It seems to be the procedure
>>>
>>> completion-in-region--postch
>>
>> Sounds like bug#41423.
>> If that's the case, then I suggest you try the code in Emacs's `master`
>> where it should be fixed.
>
> It really sounds like bug#41423, even because the workaround provided by
> Gregory Heytings solves the problem, that is, I don't notice any slow
> down after applying:
>
> (add-hook
> 'eshell-mode-hook
> (function (lambda ()
> (setq completion-at-point-functions '(pcomplete t)))))
>
> On the other hand, applying your patch...
>
> diff --git a/lisp/eshell/em-cmpl.el b/lisp/eshell/em-cmpl.el
> index faf749d836..744be525ec 100644
> --- a/lisp/eshell/em-cmpl.el
> +++ b/lisp/eshell/em-cmpl.el
> @@ -399,16 +399,21 @@
>
> (defun eshell-complete-commands-list ()
> "Generate list of applicable, visible commands."
> - (let ((filename (pcomplete-arg)) glob-name)
> + ;; Building the commands list can take quite a while, especially over Tramp
> + ;; (bug#41423), so do it lazily.
> + (let ((glob-name
> + ;; When a command is specified using `eshell-explicit-command-char',
> + ;; that char is not part of the command and hence not part of what
> + ;; we complete. Adjust `pcomplete-stub' accordingly!
> + (if (and (> (length pcomplete-stub) 0)
> + (eq (aref pcomplete-stub 0) eshell-explicit-command-char))
> + (setq pcomplete-stub (substring pcomplete-stub 1)))))
> + (completion-table-dynamic
> + (lambda (filename)
> (if (file-name-directory filename)
> (if eshell-force-execution
> (pcomplete-dirs-or-entries nil #'file-readable-p)
> (pcomplete-executables))
> - (if (and (> (length filename) 0)
> - (eq (aref filename 0) eshell-explicit-command-char))
> - (setq filename (substring filename 1)
> - pcomplete-stub filename
> - glob-name t))
> (let* ((paths (eshell-get-path))
> (cwd (file-name-as-directory
> (expand-file-name default-directory)))
> @@ -455,7 +460,7 @@
> (and eshell-show-lisp-alternatives
> (null completions)))
> (all-completions filename obarray #'functionp))
> - completions)))))))
> + completions)))))))))
>
> (define-obsolete-function-alias 'eshell-pcomplete #'completion-at-point "27.1")
>
> ...does not make any noticeable change.
[...]
Sorry! It does make a noticeable change. Your patch seems to solve the
problem quite well for me. I believe this is case closed. Thank you
for the marvelous patch.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: why is my cd command on eshell on Windows so slow?
2021-04-17 8:28 ` Wayne Harris via Users list for the GNU Emacs text editor
@ 2021-04-17 14:08 ` Stefan Monnier
2021-04-17 14:32 ` Óscar Fuentes
0 siblings, 1 reply; 12+ messages in thread
From: Stefan Monnier @ 2021-04-17 14:08 UTC (permalink / raw)
To: help-gnu-emacs
>> ...does not make any noticeable change.
>
> [...]
>
> Sorry! It does make a noticeable change. Your patch seems to solve the
> problem quite well for me. I believe this is case closed. Thank you
> for the marvelous patch.
I'm glad I saw your message yesterday at a bad time and decided
to "reply to it later" ;-)
Stefan
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: why is my cd command on eshell on Windows so slow?
2021-04-17 14:08 ` Stefan Monnier
@ 2021-04-17 14:32 ` Óscar Fuentes
2021-04-17 14:39 ` Eli Zaretskii
2021-04-17 14:41 ` Stefan Monnier
0 siblings, 2 replies; 12+ messages in thread
From: Óscar Fuentes @ 2021-04-17 14:32 UTC (permalink / raw)
To: help-gnu-emacs
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> ...does not make any noticeable change.
>>
>> [...]
>>
>> Sorry! It does make a noticeable change. Your patch seems to solve the
>> problem quite well for me. I believe this is case closed. Thank you
>> for the marvelous patch.
>
> I'm glad I saw your message yesterday at a bad time and decided
> to "reply to it later" ;-)
So the problem is fixed in master but not in emacs-27. Is it planned to
be backported to the later? It is a regression.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: why is my cd command on eshell on Windows so slow?
2021-04-17 14:32 ` Óscar Fuentes
@ 2021-04-17 14:39 ` Eli Zaretskii
2021-04-17 14:56 ` Óscar Fuentes
2021-04-17 14:41 ` Stefan Monnier
1 sibling, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2021-04-17 14:39 UTC (permalink / raw)
To: help-gnu-emacs
> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 17 Apr 2021 16:32:14 +0200
>
> So the problem is fixed in master but not in emacs-27.
Yes.
> Is it planned to be backported to the later? It is a regression.
It was found too late to be safe enough for the emacs-27 branch, so
no. (I'm not sure at this point that there will be another Emacs 27.x
release.)
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: why is my cd command on eshell on Windows so slow?
2021-04-17 14:32 ` Óscar Fuentes
2021-04-17 14:39 ` Eli Zaretskii
@ 2021-04-17 14:41 ` Stefan Monnier
1 sibling, 0 replies; 12+ messages in thread
From: Stefan Monnier @ 2021-04-17 14:41 UTC (permalink / raw)
To: help-gnu-emacs
> So the problem is fixed in master but not in emacs-27. Is it planned to
> be backported to the later?
Not currently, no.
> It is a regression.
I wouldn't mind backporting it to `emacs-27`, but you'd better ask Eli
if he thinks it's worth the risk (he's the one who decides what is
acceptable on the `emacs-27` branch).
Stefan
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: why is my cd command on eshell on Windows so slow?
2021-04-17 14:39 ` Eli Zaretskii
@ 2021-04-17 14:56 ` Óscar Fuentes
2021-04-17 15:05 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Óscar Fuentes @ 2021-04-17 14:56 UTC (permalink / raw)
To: help-gnu-emacs
Eli Zaretskii <eliz@gnu.org> writes:
>> So the problem is fixed in master but not in emacs-27.
>
> Yes.
>
>> Is it planned to be backported to the later? It is a regression.
>
> It was found too late to be safe enough for the emacs-27 branch,
Looking at the dates on the bug report, I guessed that was the reason.
> so no. (I'm not sure at this point that there will be another Emacs
> 27.x release.)
So the answer is that if 27.3 is released, it will not include the fix?
Too bad, because right now using Eshell on Windows is quite annoying.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: why is my cd command on eshell on Windows so slow?
2021-04-17 14:56 ` Óscar Fuentes
@ 2021-04-17 15:05 ` Eli Zaretskii
0 siblings, 0 replies; 12+ messages in thread
From: Eli Zaretskii @ 2021-04-17 15:05 UTC (permalink / raw)
To: help-gnu-emacs
> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 17 Apr 2021 16:56:24 +0200
>
> > so no. (I'm not sure at this point that there will be another Emacs
> > 27.x release.)
>
> So the answer is that if 27.3 is released, it will not include the fix?
I don't know, it depends on what would be the reasons for releasing
27.3 and when this will happen.
> Too bad, because right now using Eshell on Windows is quite annoying.
You can always install the fix in your own Emacs, if you need the fix
badly.
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2021-04-17 15:05 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-04-16 18:40 why is my cd command on eshell on Windows so slow? Wayne Harris via Users list for the GNU Emacs text editor
2021-04-16 18:59 ` Eli Zaretskii
2021-04-16 20:14 ` Wayne Harris via Users list for the GNU Emacs text editor
2021-04-16 21:14 ` Stefan Monnier
2021-04-17 0:10 ` Wayne Harris via Users list for the GNU Emacs text editor
2021-04-17 8:28 ` Wayne Harris via Users list for the GNU Emacs text editor
2021-04-17 14:08 ` Stefan Monnier
2021-04-17 14:32 ` Óscar Fuentes
2021-04-17 14:39 ` Eli Zaretskii
2021-04-17 14:56 ` Óscar Fuentes
2021-04-17 15:05 ` Eli Zaretskii
2021-04-17 14:41 ` Stefan Monnier
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).