git_prompt_status is slow on cygwin

[TheDauthi]

git_prompt_status is rather slow on cygwin, and on other platforms where spawning a subshell is slow.
Two cases:
(first, just calling the function, second is inside a fresh linux kernel tree. )

TheDauthi@Hera:~$ time (git_prompt_status)
( git_prompt_status; )  0.21s user 0.41s system 97% cpu 0.636 total
TheDauthi@Hera:~/Projects/linux$ time (git_prompt_status)
( git_prompt_status; )  2.41s user 9.50s system 228% cpu 5.216 total

(Not much we can do about the second one, it's due to the slowness of the git status itself)
Identical setup on linux:

billyconn@Hades:~$ time (git_prompt_status)
( git_prompt_status; )  0.00s user 0.01s system 16% cpu 0.047 total
billyconn@Hades:~/Projects/linux$ time (git_prompt_status)
( git_prompt_status; )  0.06s user 0.08s system 85% cpu 0.173 total

Tracking this down, it's the spawning of the greps (which is no shock; cygwin emulation of fork is well-known, and grep is somehow particularly slow). I rewrote this function to use zsh builtins and an ugly bit of sed instead of spawning greps:

Cygwin:

TheDauthi@Hera:~$ time (git_prompt_status)
( git_prompt_status; )  0.07s user 0.04s system 117% cpu 0.102 total
TheDauthi@Hera:~/Projects/linux$ time (git_prompt_status)
( git_prompt_status; )  2.30s user 8.75s system 241% cpu 4.567 total

It's faster on linux, too, but linux was already fast:
Linux:

billyconn@Hades:~$ time (git_prompt_status)           
( git_prompt_status; )  0.00s user 0.00s system 0% cpu 0.008 total
billyconn@Hades:~/Projects/linux$ time (git_prompt_status)
( git_prompt_status; )  0.06s user 0.09s system 104% cpu 0.137 total

https://github.com/TheDauthi/git-prompt-status

I didn't make a pull request; this is in a frequently-used lib so I didn't want to touch it without testing, if there's even interest in using a modified version. I wrote a FEW tests (they're in the test directory), but will try to add more. I also would like to know if/how you typically integrate tests, as what's there is just something I hacked up in a couple of hours.

Not sure how the command works on OSX yet, don't have a machine to test on until Monday. I suspect that the sed statements will need to be re-quoted. Wanted to gauge interest and get feedback before continuing.

[mcornella]

Feel free to make a PR, I'm all for using all zsh builtins. Thanks!

[igitur]

Was this ever PR'ed / merged?

[TheDauthi]

I made a PR, but it was never merged.

There's also a sed-based version in that linked repo. It's even faster (another multiple) because it only counts unique status lines. But I never got around to testing it on BSD platforms, and it doesn't use ZSH builtins.

[igitur]

Ok, thanks. Bit of a side question: how did you track down the cause of the slow prompt? Even after using your sed-based version, my prompt it still slow and I suspect it's the damn corporate anti-virus. But I need a way to verify that.

[TheDauthi]

I started out by looking at the outputs of echo $PROMPT, echo $RPROMPT, echo $RPROMPT2 and echo $PROMPT_COMMAND. That shows what functions are being called before/after each prompt. Testing each function separately using $(function-name) will show which one is taking its time. From there, it's just a matter of taking apart the functions individually.

If you're on Cygwin, I'd give it an 98% chance of being extra subshells or commands (especially grep) being executed. Forking and running commands (including subshells) is extremely slow on cygwin, because it's not really forking, it's creating a process and then cloning the previous command's entire data segment, stack, heap, etc. manually into the new process. The Windows kernel itself does support forking, but that functionality isn't exposed to the win32 subsystem.

If you're on another environment, the only real things I've seen used that killed performance in a prompt was a plugin function that scanned and parsed the history file and rewrote it after every command and one that was trying to do a git fetch after every one.

[igitur]

@TheDauthi Yes, I'm on babun (cygwin + extras). Turns out it was the anti-virus. It does a real-time scan for every fork, which exacerbates the issue. Thanks for your help.

[TheDauthi]

That's interesting. I'd suspect that with the extra work with the anti-virus, the pure-shell-parser version would be the faster one. That means that the sed one should be faster in some cases, but the pure shell one would be a more consistent improvement.

Too bad we need the 'stashed' status, or we could cut the number of forks in half. On Cygwin, it might actually be better iterating up the directory tree for that status, looking for .git/refs/stash, since we don't care about anything other than whether there is a stash or not. But that change would be better served by a plugin, since it's a Cygwin-only hack.

EDIT: @igitur the other issue you linked to is exactly what caused me to write this. I also use babun and had switched to the theme I normally use from Linux.

[robbyrussell]

@TheDauthi could you link to your PR for me?

[TheDauthi]

#5531.

It also provides more data for someone to use if someone wanted (the count of each type of modification), and would be trivially easy to change the order. There's no extra work being done, it's just a side-effect of how it's being counted now.

I'll be happy to fix any problems found. It's been tested somewhat (linked repo), but that's no guarantee that I didn't miss anything.

[iegik]

1. On git status there are hooks lounched and checks for EOL /whitespaces and so on. In Windows there is some troubles with core.autocrlf. So, if You have large project, git will check each file state.... it will be a lot of resource usage.
2. The main feature (light one) is detecting branch name. It can be done with parsing content of .git/HEAD. Easy.
3. I think getting state of uncommited files and getting branch/pushed content history state should be seporate process.

Also checkout https://gist.github.com/sindresorhus/3898739.