tl;dr: vcs/git prompt in Powerlevel10k is now even faster; if you are already using Powerlevel10k, pull the new version; if you aren't, give it a try; if you are curious about the implementation, read on.
Compatible with Prezto and oh-my-zsh.
I patched libgit2—the official git C API that gitstatusd uses—to make it faster on large repos.
- optimized a few hot string functions
- removed
.gitignore
checks where they make no difference, such as when we only need unstaged files
- extended the diffing API to allow parallel multi-threaded scans
Building gitstatusd now required the patched libgit2 from https://github.com/romkatv/libgit2/. It won't compile with the stock one. To make building easier, I wrote https://github.com/romkatv/gitstatus/blob/master/build.zsh that pulls and builds gitstatusd with the right version of libgit2. This is the script I use myself to build gitstatusd on Linux, Mac OS, FreeBSD and Raspberry Pie.
I implemented several optimizations in gitstatusd.
- use the new diffing API I added to libgit2 to perform scans in parallel from multiple threads
- remember unstaged, staged and untracked files from the last request and check them on the next; chances are, these files still have the same status (or some other interesting status), so fewer scans will be necessary
- check for staged files (
git_diff_tree_to_index
) in parallel with dirty (git_diff_index_to_workdir
)
The most hardcore bits of the code are in git.cc.
The overall effect of these optimizations is that git segment in Powerlevel10k now renders at least 4x faster on large repos with tens of thousands or hundreds of thousands of files. On small repos it's also faster but it makes no practical difference. The worst case is when the repo is clean, so gitstatusd has to scan everything on every prompt (this is when it's "only" 4x faster than before). The best case is where you have staged, unstaged and untracked files. Here gitstatusd will be virtually instant regardless of the size of the repo because it won't scan anything.
I've tuned performance parameters—things like shard size and the total number shards when doing parallel scans—on my dev machine, which is a real beast. It's possible that it doesn't perform as well if you have a git repo on HDD. Unfortunately, I don't have any machine with an HDD, so I cannot check this myself. If you do, please try the new Powerlevel10k on a large git repo with different values of GITSTATUS_NUM_THREADS
. Your git prompt must get grey or the repo isn't large enough. GITSTATUS_NUM_THREADS
controls the level of parallelism in gitstatusd. It defaults to the number of CPU cores you have but maybe a lower value is better for HDD. The parameter must be set before you source Powerlevel10k. The minimum value is 1.
originally posted on rdt
[–]ikidd 1 insightful - 1 fun1 insightful - 0 fun2 insightful - 0 fun2 insightful - 1 fun - (1 child)
[–]akerro[S] 1 insightful - 1 fun1 insightful - 0 fun2 insightful - 0 fun2 insightful - 1 fun - (0 children)