From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id bee3d54a for ; Fri, 8 Nov 2019 10:25:38 +0000 (UTC) Received: (qmail 24895 invoked by alias); 8 Nov 2019 10:25:33 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 44902 Received: (qmail 24748 invoked by uid 1010); 8 Nov 2019 10:25:33 -0000 X-Qmail-Scanner-Diagnostics: from out5-smtp.messagingengine.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.0/25622. spamassassin: 3.4.2. Clear:RC:0(66.111.4.29):SA:0(-2.6/5.0):. Processed in 4.677763 secs); 08 Nov 2019 10:25:33 -0000 X-Envelope-From: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at daniel.shahaf.name does not designate permitted sender hosts) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= daniel.shahaf.name; h=date:from:to:subject:message-id:references :mime-version:content-type:content-transfer-encoding :in-reply-to; s=fm1; bh=1qiIrPu9Ja93Ct88UFlPYP89Y4L3lcpJwhIBTfJ8 LqY=; b=l97vths9bhmM7r0T7n65ItRpjihKOWXd/lMZ+eK2xnGuALDOe2snsSo9 Mhm2diRpnh1vizpGb+9EWECY4q0nSHz69r1i+ANLAbIN1x8QztSP0SYJ42jFEkzT i7+i32VQOiNtN05cSDmuPDk3yAOCIr9D89ih2gqCd2j2w9S7SYaNH455+brS/+GV MRKHKACyYtXFzUUBC3TlUinSAq9jZWilN0ozAW4tU5HvKvItjVK9tDDeU5wVyoix SSjCDCZ6I+ddJ6Ns/C9hSmoljQD8w+WoJXXon8lDWkobq18DlfNeUHWpkCFPUj+t Jubrq4/68eJLKgMRsrp3XaHKuF3zdQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=1qiIrPu9Ja93Ct88UFlPYP89Y4L3lcpJwhIBTfJ8L qY=; b=tlRjAGuAvbvaFAUcV5p91BJLmyyDvI/yAd+VGB23WlwHb9SfHlTTGD+F9 EiL+F09FmuGcNyx5CRzd8Mw+yRmtdIXBJWt+R3yqT5TtiQO1ljLX2ibfdJ7yELHV 0rRBM2qUIo9qAEZZrTkQLCkWs24Rhu8jUD67Psr9A9V+yeIEA+eHsqeuUTYQ5eSn GJe73HgoHg/btE86VOUUMAODthfi6t34f+oujW+HS3T7BxpS977tE4/j/3i+7wk1 9JMIAcEZarspjTHZNs1hQo5k8b4ZUoMwhJtjgjpwctPV5k4RqShqsmNFqx4fWco7 cDX5+/pDXo2NUdbISmkNIDehu6EPQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddvuddgudeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggugfgjfgesth ektddttderjeenucfhrhhomhepffgrnhhivghlucfuhhgrhhgrfhcuoegurdhssegurghn ihgvlhdrshhhrghhrghfrdhnrghmvgeqnecukfhppeejledrudektddrheejrdduudelne curfgrrhgrmhepmhgrihhlfhhrohhmpegurdhssegurghnihgvlhdrshhhrghhrghfrdhn rghmvgenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Date: Fri, 8 Nov 2019 10:24:46 +0000 From: Daniel Shahaf To: Zsh hackers list Subject: Re: VCS_info seems really slow on remote filesystem Message-ID: <20191108102446.w7vnufdrvy7hj7bp@tarpaulin.shahaf.local2> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Bart Schaefer wrote on Thu, Nov 07, 2019 at 19:41:13 -0800: > After some fiddling around to enable function tracing I discovered > that VCS_INFO_detect_git is trying two different "git rev-parse" calls > and also looking for two subdirectories, and that > VCS_INFO_git_getbranch is looking for five more directories and four > files. Those directory/file existence tsts are all slow operations on > this filesystem, and in at least some of the cases appear to be tests > that would only need to be done if the current directory changed? The tests are also needed if a git command has been run from another shell. For example, if you run «git checkout master» in one shell and then press on an empty command line in another shell, that other shell will re-run vcs_info. Is the check-for-changes style set? > Is there anyone more familiar than I with the implementation than I, > who could determine whether any of this information could be cached > instead of being regenerated on every precmd? > Possibly. Question (to the list): Can we invalidate the cache automatically? For example, could we avoid running all those file/directory existence tests in VCS_INFO_git_getbranch unless the mtime of .git/ has changed since the last call? This way, we'd do fewer checks in all cases, not just in slow mountpoints. > (I've seen gitstatus recommended in another thread, but it's not > feasible to install the binary daemon in the circumstances where I'm > encountering this.) As a last resort, you can set the disable-patterns style, but it disables vcs_info completely for the directories it matches; even running vcs_info interactively at the prompt won't bypass it. (Arugably it should, though…)