Performance data of gitstatus and alternatives with bash-seafly-prompt, including fsmonitor

[bluz71]

Hello @romkatv,

You may be interested in the following performance data I gathered for my bash-seafly-prompt.

Historically I provided two ways to gather Git status, either use this gitstatus utility or fallback to git command to gather: branch, dirty, stage, upstream and stash state via separate invocations of git.

Recently I learned that Git 2.11 (Nov 2016) includes a new porcelain=v2 option which can gather all my required states (branch, dirty, upstream, stash etc) in one swoop. However, I soon learned that running grep and awk is really slow. So instead I created a simple Rust utility git-status-fly to run and parse porcelain=v2 using optimized Rust.

Meanwhile I came across #370 and the new core.fsmonitor option and I wondered how that would effect matters.

So I ran performance tests on my two systems:

• Mid-range Core i5 Linux desktop with SATA SSD
• M1 Macbook Air

Against these four repositories:

• dotfiles, small repository with 189 managed files
• rails, medium repository with 4,574 managed files
• linux, large repository with 79,878 managed files
• chromium, extra large repository with 413,542 managed files

Note, core.fsmonitor only works on Windows and macOS, not Linux (sadly). Also, feature.manyFiles provides benefits (especially on macOS) against large and very large repositories (so I enabled it for linux and chromium repositories).

Listed is the average time to compute the prompt function in a git repository.

Linux performance results:

Repository	git-status-fly	gitstatus	git fallback
dotfiles	16ms	12ms	28ms
rails	21ms	15ms	33ms
linux	61ms	42ms	80ms
chromium	260ms	160ms	305ms

Macbook performance results (also with fsmonitor results):

Repository	git-status-fly	git-status-fly + fsmonitor	gitstatus	git fallback	git + fsmonitor fallback
dotfiles	32ms	45ms	12ms	61ms	87ms
rails	45ms	45ms	29ms	73ms	89ms
linux	175ms	60ms	165ms	211ms	105ms
chromium	2700ms	102ms	2500ms	2600ms	155ms

gitstatus is not fsmonitor aware so with or without fsmonitor the same results were produced.

fsmonitor is big win for large and very large repositories, but for small to medium sized repositories it is a performance degradation. So it should only be enabled on a per-repository basis.

Invoking a process on macOS is quite slow, much slower than Linux. gitstatus being a daemon has benefits, but at the cost of adding an extra 20ms to terminal+shell startup time.

Note, a prompt time of 30ms - 35ms or less feels instant.

gitstatus overall still has the best performance, but my git-status-fly utility is reasonably good too.

Anyway, there is no issue here, I just thought you may be interested in these results.

Cheers.

[romkatv]

Thanks for sharing the data! Super useful stuff.

[bluz71]

Adding in starship Cross-Shell Prompt results, just because I was curious.

I used starship with out-of-the-box settings, no configuration.

Linux:

Repository	git-status-fly	gitstatus	git fallback	starship
dotfiles	16ms	12ms	28ms	38ms
rails	21ms	15ms	33ms	45ms
linux	61ms	42ms	80ms	132ms
chromium	260ms	160ms	305ms	790ms

macOS (fsmonitor enabled for linux and chromium repositories):

Repository	git-status-fly	gitstatus	git fallback	starship
dotfiles	32ms	12ms	61ms	70ms
rails	45ms	29ms	73ms	93ms
linux	60ms	165ms	105ms	120ms
chromium	102ms	2500ms	155ms	340ms

starship is implemented in Rust, but it's Git & other processing is slow. Not my problem since I use my own seafly prompt on Bash, but starship is way slower than it should be, I am very surprised since so many people use it. Too much bloat? Too much shelling out? It is a sluggish prompt in-my-experience.

[romkatv]

Thought you might appreciate how we measure shell performance in zsh: https://github.com/romkatv/zsh-bench. It mentions Starship, too (it's very slow).

[bluz71]

Very interesting indeed.