Async getStatus? #16

Open
demian85 opened this Issue Jan 9, 2014 · 8 comments

Projects

None yet

3 participants

@demian85
demian85 commented Jan 9, 2014

getStatus is really slow for big repositories and freezes my app UI (node-webkit) during the execution of that method.
I think the solution is an async version to avoid freezing the main UI/DOM thread when performing computations.
Maybe I could use workers, but why is that method taking so much time? 2+ seconds...

@kevinsawicki
Member

Are you calling it with a path or with no arguments?

If you are calling it without a path then it is probably best to run it in a separate child process since it can take some time for large repositories.

Adding an async version would work too but that isn't supported yet.

@demian85
demian85 commented Jan 9, 2014

I'm calling that method with no arguments. But still, I don't understand
why is it so slow.
I need to get the initial status when the app is loaded.
Executing 'git status' is way too fast compared to it!

On Thu, Jan 9, 2014 at 1:47 PM, Kevin Sawicki notifications@github.comwrote:

Are you calling it with a path or with no arguments?

If you are calling it without a path then it is probably best to run it in
a separate child process since it can take some time for large repositories.

Adding an async version would work too but that isn't supported yet.


Reply to this email directly or view it on GitHubhttps://github.com/atom/git-utils/issues/16#issuecomment-31951695
.

@kevinsawicki
Member

Hmm, yeah, not sure why it would be slower than git status at the command line, worth looking into.

Is the repo you are trying it out on public?

@demian85
demian85 commented Jan 9, 2014

mm no sorry, it's a private intranet web app, but i can tell you it has at
least three thousand files inside... :P

On Thu, Jan 9, 2014 at 1:59 PM, Kevin Sawicki notifications@github.comwrote:

Hmm, yeah, not sure why it would be slower than git status at the command
line, worth looking into.

If the repo you are trying it out on public?


Reply to this email directly or view it on GitHubhttps://github.com/atom/git-utils/issues/16#issuecomment-31953039
.

@demian85

Could take a look at this? Or should I report the issue in the libgit repo?

@kevinsawicki
Member

I'll take a look, but it make take me some time to find a repo that reproduces the behavior you are seeing.

@demian85

I think you just need to be sure nothing weird is going on inside that function.
It seems that the whole directory contents are scanned recursively every time the function is called, and just to get status information. Shouldn't that be cached somehow? How does Git do it?
A temp solution for me could be to just parse git statusoutput :/

@demian85

I've just implemented my own getStatus parsing git status --porcelain -z output and realized there is missing info in your method that could be useful: unmerged paths.

@smashwilson smashwilson referenced this issue in smashwilson/merge-conflicts Mar 15, 2014
Open

Use git-util instead of shelling out to git. #12

@probablycorey probablycorey added the bug label Jun 24, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment