Running git-radar --bash is slow

[miguelmota]

In a repository with a .git folder that is ~30MB big, it's takes around ~6 seconds to run git-radar --bash which is too slow, especially when constantly opening new terminal sessions. Is there any way to speed up the command or is this a limitation that can't can't be optimized? Thanks.

[neozenith]

Not having looked into the depths of git-radar but it is definitely fixable. I made my own "Poor man's git-radar" and had a similar issue. The trick was to bail out of any further processing if you can avoid it.

eg,

1. If git branch returns nothing, bail out all other work.
2. If git status returns nothing, bail out
3. Avoid reflog. I can't remember why but a snippet that suggested how to scrape some information worked for small repos but big ones took 15 secs to get a prompt to load....
4. Use git cherry to figure out the difference in commits between remote branches and the local tracking branch.

As to debugging which parts of git-radar --bash are taking up so much time... not sure.

[michaeldfallen]

Definitely can be optimised. I've fell out of maintaining git-radar due to it satisfying my need but it's been nagging me that it is slow.

As @neozenith says there are optimisations that can be made but ultimately Bash is slow at processing strings.

I'm tempted to reimplement fairly soon using a faster language that can access the libgit2 instead, thus optimising usage of git as well. Go would probably be a good choice.

[neozenith]

Maintenance @michaeldfallen as a starting point I'd be happy to be assigned this issue and work through some test cases to improve the speed.

Also the git-radar organisation on github isn't taken yet. Completely up to you but if you wanted to move this project off your personal account and let become a V1.0 community endeavour that is an option. In a weird way I kind of like that it is all bash scripts. From the git-radar organisation you can spin up the GoLang implementation.

Another option is keep it all here. I'd be happy to step up as a maintainer, triage issues, run code reviews etc. Not sure if you have elevated anyone to a maintainer status already or not.

It's a really well developed project (just look at that README) and I personally think it'd be a shame to let it go quiet. I get quite a few comments from colleagues about my poor man's version that they'd like to have it too. https://github.com/neozenith/vim-dotfiles#git-bash-prompt

Possible Test Cases Back to the core issue though if I am picking it up...

I know a good repository that is notoriously large to test this against. YouCompleteMe autocomplete engine.

There was another one that a company I was working for had python scripts generating and updating C++ files that were version controlled that would be good tests.

Even having a sample repo commit node_modules and then each week blow away package-lock.json and npm install latest dependency trees would be a good test.