From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Wayne Harris via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> Newsgroups: gmane.emacs.help Subject: Re: why is my cd command on eshell on Windows so slow? Date: Fri, 16 Apr 2021 17:14:17 -0300 Message-ID: <86sg3qouli.fsf@protonmail.com> References: <86r1jaqdia.fsf@protonmail.com> <83r1javyvo.fsf@gnu.org> Reply-To: Wayne Harris <wharris1@protonmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38110"; mail-complaints-to="usenet@ciao.gmane.io" To: help-gnu-emacs@gnu.org Cancel-Lock: sha1:CckL1h5XkiFK+Sl1mspy7/y/O9E= Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Fri Apr 16 22:15:24 2021 Return-path: <help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org> Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org>) id 1lXUs7-0009oV-SL for geh-help-gnu-emacs@m.gmane-mx.org; Fri, 16 Apr 2021 22:15:23 +0200 Original-Received: from localhost ([::1]:52290 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from <help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org>) id 1lXUs6-0001Oe-Vx for geh-help-gnu-emacs@m.gmane-mx.org; Fri, 16 Apr 2021 16:15:23 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35692) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <geh-help-gnu-emacs@m.gmane-mx.org>) id 1lXUrI-0001CD-Gt for help-gnu-emacs@gnu.org; Fri, 16 Apr 2021 16:14:32 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]:40266) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <geh-help-gnu-emacs@m.gmane-mx.org>) id 1lXUrG-0005oj-8r for help-gnu-emacs@gnu.org; Fri, 16 Apr 2021 16:14:32 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from <geh-help-gnu-emacs@m.gmane-mx.org>) id 1lXUrD-0008gB-BL for help-gnu-emacs@gnu.org; Fri, 16 Apr 2021 22:14:27 +0200 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=geh-help-gnu-emacs@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor <help-gnu-emacs.gnu.org> List-Unsubscribe: <https://lists.gnu.org/mailman/options/help-gnu-emacs>, <mailto:help-gnu-emacs-request@gnu.org?subject=unsubscribe> List-Archive: <https://lists.gnu.org/archive/html/help-gnu-emacs> List-Post: <mailto:help-gnu-emacs@gnu.org> List-Help: <mailto:help-gnu-emacs-request@gnu.org?subject=help> List-Subscribe: <https://lists.gnu.org/mailman/listinfo/help-gnu-emacs>, <mailto:help-gnu-emacs-request@gnu.org?subject=subscribe> Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" <help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org> Xref: news.gmane.io gmane.emacs.help:129011 Archived-At: <http://permalink.gmane.org/gmane.emacs.help/129011> 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---