-
Notifications
You must be signed in to change notification settings - Fork 325
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for incremental statistics #22
Comments
Original comment by
|
Can this be connected to following problem? After some massive changes in repo gitinspector consumes all the CPU with a lot of Can anything be tuned to speedup processing or at least to reduce CPU usage? |
Hi @imposeren. Gitinspector is quite slow on very large repos with a big history, as it blames every single file. This would partly solve it, yes. When this feature is implemented (assuming it's possible) it would mean gitinspector would not have to re-blame every single file each time you run it. Instead, it would only process the files that changed since last time, making it substantially less painful. The only thing you can really do to speed up processing is to not use the "-H" (hard) option. If you were not using it - you are out of luck. The only option would be to optimize git itself :). |
Thanks for reply. Maybe there are some options for optimizing history? Something like this: But I do not know if removing unused files from history will affect gitinspector as it seems to operate only on existing files (cs this the correct?) |
Yes. Just running "git gc" will speed things up. Sometimes quite significantly. If you have never done it before, passing the --agressive switch might be a good idea. The following is from the git docs;
I'm not sure how much the other stuff in that article will affect processing speed, but I guess it's always worth a try. The blame section of gitinspector only operates on existing files, yes. However, with the -H flag, git still scans the whole history in order to be able to correctly blame each row to each author. So I guess even "git blame" should run faster. A blamed row can also, for example be from one of those big files so it still needs to take them into account, to some extent (even without -H passed to gitinspector). Hard to say without a deeper investigation into the inner workings of git itself. |
@adam-waldenberg |
No. It does not. |
Neither does it blame any files that have an invalid extension. Binary files are also skipped. |
is there any way to reduce concurrency of git blame? I can see up to 8 |
I can already see that there are no such options: I'll create separate issue for these and maybe will make a pull request later |
Gitinspector starts as many processes as there are threads/cores. There is no configuration option for it, and never will be. However, there is a constant at the top of changes.py and blame.py that controls the number of threads. |
Original issue reported on code.google.com by
[email protected]
on 15 Nov 2013 at 12:50The text was updated successfully, but these errors were encountered: