From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#41423: 27.0.91; eshell file completion in tramp dir is slow (3 minutes) [regression on pretest] Date: Tue, 01 Sep 2020 00:23:54 -0400 Message-ID: References: <87mu2d7hka.fsf@gmx.de> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8862"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Michael Albinus , rrandresf@gmail.com, Tim Vaughan , 41423@debbugs.gnu.org To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Sep 01 06:25:10 2020 Return-path: Envelope-to: geb-bug-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 ) id 1kCxr3-0002De-LA for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 01 Sep 2020 06:25:10 +0200 Original-Received: from localhost ([::1]:56750 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kCxr2-0002ha-O3 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 01 Sep 2020 00:25:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53714) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kCxqw-0002hO-81 for bug-gnu-emacs@gnu.org; Tue, 01 Sep 2020 00:25:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42944) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kCxqv-0004Gq-Tf for bug-gnu-emacs@gnu.org; Tue, 01 Sep 2020 00:25:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kCxqv-00084d-Pm for bug-gnu-emacs@gnu.org; Tue, 01 Sep 2020 00:25:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 01 Sep 2020 04:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41423 X-GNU-PR-Package: emacs Original-Received: via spool by 41423-submit@debbugs.gnu.org id=B41423.159893425330959 (code B ref 41423); Tue, 01 Sep 2020 04:25:01 +0000 Original-Received: (at 41423) by debbugs.gnu.org; 1 Sep 2020 04:24:13 +0000 Original-Received: from localhost ([127.0.0.1]:54490 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kCxq9-00083H-Bv for submit@debbugs.gnu.org; Tue, 01 Sep 2020 00:24:13 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:19310) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kCxq6-000832-Mx for 41423@debbugs.gnu.org; Tue, 01 Sep 2020 00:24:11 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 0FFAB80712; Tue, 1 Sep 2020 00:24:05 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 32D1680513; Tue, 1 Sep 2020 00:24:03 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1598934243; bh=7FjurgGv+xAhtzaP7RQ9XaOUHzo2/4PfbsMbKJnomIs=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=QmZSYL2ZKuJ5m9ipqtZrlqRII4difdroaAXJUrwxbXj9hZX5WGK+icOshkiSna4yQ iPrB4/nalylur1zkCjkyjTDRoPkCQuE5+3S1AgBtZn+aUagQOJB9TJuB121VqsJxLq 5Gd9LCfyXSlmbM6GoepmeVEGSvCLF8cUBa0QwiJOkfqyte+9YTTfGpk8Jc1CLWQYD+ JceIqt37w3G0LIP2ZAU7i//uZJhB5UuTnKvS0SuROS6utrVVBZ35H8TmKppZHWG7mE kZNtOrpaUuWnKuGBP14lfR9XdTo+JuvbSV6/zTjOa7E8wK8VlT3G4RxTIEWGpuudo5 Z5wIBsfBiotHA== Original-Received: from alfajor (unknown [45.72.232.131]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E89BB1202FB; Tue, 1 Sep 2020 00:24:02 -0400 (EDT) In-Reply-To: (Gregory Heytings's message of "Sun, 30 Aug 2020 22:28:01 +0000") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:186813 Archived-At: > I do not understand why I should explain to you how the code you wrote > works. [ Because I remember ow it's supposed to work, but I don't know how it actually behaves in this specific case. ] > 19. given that the value of the start position did not change, the lambda > let-bound at step 8 returns t, and therefore completion-in-region--postch > does not exit completion-in-region-mode > 20. completion-in-region--postch is now finished, it did not change > anything in the eshell buffer > 21. RET is pressed > 22. post-command-hook is executed, and still contains > completion-in-region--postch, so it is called again > 23. completion-in-region--postch calls completion-in-region-mode-predicate > 24. this calls pcomplete-completions-at-point a third time, which calls > pcomplete-completions Looks OK so far. > 25. for some reason, pcomplete-completions considers that it must now > complete a command name and not a directory name I guess this is because after RET we're now at BOL so it looks like a brand new command is starting. > 26. therefore pcomplete-completions does not call pcomplete/cd but > eshell-complete-commands-list I guess this is the culprit and this is where the time is spent. `eshell-complete-commands-list` eagerly builds the list of possible candidates and it takes a while whereas we should here return something quickly and cheaply, e.g. by returning a function which will build and return this list more lazily when completion is actually performed. Of course, the slowdown will presumably still be seen when you do actually want to complete a command name, so we should probably try and figure out more precisely where the slowdown comes from and how to avoid/reduce it. I guess part of the slowdown comes from the fact that we don't just use `file-name-all-completions` in each directory in PATH but we additionally call `file-executable-p` (or `file-readable-p`) on every command found, which I expect will take quite a while when it goes through Tramp. Still, I'm not completely sure where the time is spent because I'm not sure which files/dirs will go through tramp. AFAICT, `eshell-get-path` will return the "local" $PATH rather than that of the remote host ... oh wait, no I see that `tramp-eshell-directory-change` will set that to the remote host's $PATH, so it should indeed work correctly (but slowly). Maybe `tramp-eshell-directory-change` should tell `eshell-complete-commands-list` to cache the list and also not to bother checking `file-executable-p`? > And the last steps should be: > > 29. when eshell-complete-commands-list has finished its job, > pcomplete-completions-at-point returns a value in which the start position > has changed > 30. therefore the lambda let-bound at step 8 returns nil, and therefore > completion-in-region--postch exits completion-in-region-mode entered at step > 10 > 31. this removes completion-in-region--postch from post-command-hook > 32. eshell finally prints its next prompt Yes, these steps look fine. Stefan