git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Git status performance on PS (command prompt)

From
brian m. carlson <sandals@crustytoothpaste.net>
Date
Feb 12, 2017, 16:46 UTC
Message-ID
<20170212164650.u7frv234kmu5hm7r@genre.crustytoothpaste.net>
In-Reply-To
<CAPd6JnGC3yeDo_sB+H+UKvh-PbiC2qySC=EbaRNLbkkwYkJM4A@mail.gmail.com>
On Sun, Feb 12, 2017 at 04:53:47PM +0100, Mark Gaiser wrote:
Show 13 quoted lines
> Hi,
> 
> I'm using ZSH with some fancy prompt. In that prompt is also a quick
> git status overview (some symbols indicating if the branch is up to
> date, if there are changes, etc..
> 
> The commands that are being executed to fetch the information:
> 
> For the file status:
> git status --porcelain
> 
> For the repository status:
> git status --porcelain -b

So your prompt is running git status twice? Wouldn't it make more sense to just run it once and do a head -n 1 to filter out the branch when you need it? git symbolic-ref HEAD might work as well.

Show 15 quoted lines
> On small repositories (or even medium sized ones) this is fast, no
> problems there.
> But on larger repositories this is notably slow (i'm taking QtBase as
> an example now, but the same is true for much of the Qt repositories,
> or chromium or even the linux kernel itself). It's no problem if it's
> slow when you do "git status" on the command line. That can be
> expected to take a little while on large repositories. But in zsh
> prompts the call to git isn't asynchronous [1] so any slowdown will be
> noticed as the prompt simply doesn't completely show till after the
> command.
> 
> I did a bit of profiling in git to figure out where this slowdown comes from.
> Callgrind tells me that "read_directory_recursive" takes up ~62% of the time.
> Within that call the function "last_exclude_matching_from_list" takes
> up 49% of the time it takes to run "git status --porcelain -b".

This isn't entirely surprising. When git status runs, it checks all the files to see if the stat information is changed, and if so, updates the status. last_exclude_matching_from_list determines if the files are ignored, which is also necessary to ensure that only the proper files are listed.

That doesn't mean that there couldn't be some improvements there, though.

Show 8 quoted lines
> I don't really know how this code is supposed to work (i'm a git user,
> not a git developer), so i hope someone might be able to investigate
> this further. I can however apply patches to git locally and help out
> with testing.
> 
> Also, is there perhaps a command out there that might be better suited
> for the git status i want to show in the prompt? What i have now is
> merely from one of the oh-my-zsh themes.

I typically use the vcs_info support built into zsh[0], although that can be very slow on my phone. It performs adequately on most repositories on my laptop and server machines, though, including on the Linux kernel repo and our 2.4 and 9 GB repos at work.

I don't know that it has all the functionality that you need, as git status provides finer-grained data, but it might.

[0] Example at https://github.com/bk2204/homedir/blob/master/.zsh/prompt_bmc_setup
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204
Previous: Mark GaiserNext: Christian Couder
Message 2 of 3 in “Git status performance on PS (command prompt)”
  1. Mark GaiserFeb 12, 2017
  2. brian m. carlsonFeb 12, 2017
  3. Christian CouderFeb 13, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.