Git status takes too long- How to improve the performance of git

Hi All,

We are using git-1.8.2 version for version control. It is an centralized server and git status takes too long

How to improve the performance of git status

Git repo details:

Size of the .git folder is 8.9MB Number of commits approx 53838 (git rev-list HEAD --count) Number of branches - 330 Number of files - 63883 Working tree clone size is 4.3GB

time git status shows real 0m23.673s user 0m9.432s sys 0m3.793s

then after 5 mins real 0m4.864s user 0m1.417s sys 0m4.710s

And I have experimented the following ways 
-          -  Setting core.ignorestat to true
-          -  Git gc &git clean
-          -  Shallow clone – Reducing number of commits
-          -  Clone only one branch 
      - Git repacking - git repack -ad && git prune
-     - Cold/warm cache 

Could you please let me know, what are the ways to improve the git performance ? I have gone through the mailing lists.

Thank you, Renuka

-- View this message in context: http://git.661346.n2.nabble.com/Git-status-takes-too-long-How-to-improve-the-performance-of-git-tp7657456.html Sent from the git mailing list archive at Nabble.com.

Hi,

On Tue, Nov 15, 2016 at 02:33:12AM -0700, ravalika wrote:

That's a three (almost four) year old version of git. Your first test should be to see if an upgrade to a recent version will improve things.

A centralized server? How? git is designed to be runned locally. If you're running git on a network file system, the performance will suffer. Could you elaborate on how your environment is setup?

.git folder of 8.9 MEGABYTE and working tree of 4.3 GIGABYTE? Is this a typo?

A slow disc and empty caches are slow. Two ways of improving this is to have faster discs or make sure your cache is up to date. When I'd a really slow disc, I'd my shell to run a git status in the background to load the cache everytime I started working on a project. This is however an ugly hack that wasn't approved to be a part of git.

You could always check the --assume-unchanged bit, see the manual page for git update-index. However this is quite extreme and demanding for the user.

On Tue, Nov 15, 2016 at 11:24 AM, Fredrik Gustafsson <iveqy@iveqy.com> wrote:

[...]

If you install a recent version version, you may be able to use the untracked cache feature. (See "core.untrackedCache" in the git config documentation and --untracked-cache in the git update-index documentation.)

On Tue, Nov 15, 2016 at 02:33:12AM -0700, ravalika wrote:

Since you also posted this to the "Git for Windows" mailinglist I assume that you are using Windows. Reduce the number of files. For example split the repository into two one for documentation and one for source. Thats what I did with a converted repository that had to many files.

Windows is unfortunately very slow when it comes to handling many files and if I recall correctly ~30000 files was in a nicely handleable range for a Git repository on Windows, but that might have changed...

Cheers Heiko

Nice

-- View this message in context: http://git.661346.n2.nabble.com/Git-status-takes-too-long-How-to-improve-the-performance-of-git-tp7657456p7657457.html Sent from the git mailing list archive at Nabble.com.

On Wed, Nov 16, 2016 at 05:13:57PM +0530, Renuka Pampana wrote:

And each user will have their own copy of the repository locally on their machine? That is having done a git clone?

Why are you using --reference for a 8.9MB big clone?

The best way is to have it locally cloned. Yes the initial clone will be expensive but operations after that will be fairly smooth. You do not(!) want to execute git on one machine and having the repository beeing on an other machine (for example via a network file system, except git clone, git fetch, git push, etc.).

Can you please elaborate on this? How can you store 8.9 MB of data that will result in a 4.3 G workspace?