VCS_info seems really slow on remote filesystem

VCS_info seems really slow on remote filesystem

[Bart Schaefer]

I've been invoking vcs-info from a precmd hook and using the
git-post-backend-updown hook to update my prompt.  Recently I started
using what amounts to a WAN-mounted file system, and find my prompt
takes a couple of seconds to redraw after each command.

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?

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?

(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.)

Re: VCS_info seems really slow on remote filesystem

[Bart Schaefer]

On Thu, Nov 7, 2019 at 7:41 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> 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?

To partly answer my own question -- I've taken advantage of the fact
that I'm also using "prompt bart" which conveniently sets the global
variable $PSCMD.  So I just changed to this:

vcs-info-v() { [[ $PSCMD = git* ]] && vcs_info; RPS1=${vcs_info_msg_0_% } }
add-zsh-hook precmd vcs-info-v
add-zsh-hook chpwd vcs_info

and now my prompts are fast until I either change directories or run a
git command.  Would need tweaking if I were making significant use of
git aliases, but for now this suffices.

Re: VCS_info seems really slow on remote filesystem

[Daniel Shahaf]

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
<Enter> 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/<something> 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…)

Re: VCS_info seems really slow on remote filesystem

[Roman Perepelitsa]

On Fri, Nov 8, 2019 at 4:42 AM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> (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.)

A viable alternative to gitstatus is to call vcs_info in another
process and reset prompt when it completes. This doesn't reduce
vcs_info latency but at least your prompt won't get blocked.

Roman.