Re: Git very slow ?

[Ken Moffat <zarniwhoop@ntlworld.com>]

On Sun, Mar 08, 2015 at 05:21:22PM +0100, David Kastrup wrote:
> Kevin D <me@ikke.info> writes:
> 
> > On Sat, Mar 07, 2015 at 01:30:07AM +0000, Ken Moffat wrote:
> >> Hi, please CC me if that is not your usual fashion, because I am not
> >> subscribed.
> >> 
> >> I use git for my build scripts - those are accessed over nfs.  Since
> >> I started using 2.1 and later (I don't think I used 2.0) commands
> >> such as 'commit' take a long time before anything happens.  I
> >> assumed that the newer version meant this would take longer.
> >> 
> >> But today^Wyesterday I was bisecting the kernel on a local
> >> filesystem - even when the number of revisions left to test was in
> >> the single digits, git bisect took a long time to decide which
> >> revision should be the next one to test.  The filesystems are ext4.
> >> Is this sort of delay normal now?
> >> 
> >> What really prompted me to ask is that I ran git blame on a script,
> >> to see when I made a particular change so that I could add that
> >> information to a ticket, and almost gave up waiting because it felt
> >> as if it was taking for ever.
> >> 
> >
> > What kind of repository are we talking about? How many files, how big?
> > Git should not have become significantly slower recently.
> 
> Particularly not git-blame in 2.1.  I should be quite surprised to see
> any git-blame call running noticeably slower in 2.1 than in any
> preceding version.
> 
> What may have happened is that the repository recently got repacked
> aggressively and thus any access to older revisions got slower.
> However, that change would be mostly tied to the repository rather than
> the version of Git you access it with.
> 
That is possible - well, not recently-recently, but I might have
repacked my repo of buildscripts some time last year.  Running
 ls -al .git
in that repository gives me:
drwxr-xr-x   8 ken 100   4096 Mar  8 16:08 .
drwxr-xr-x  48 ken 100   4096 Mar  8 03:05 ..
-rw-r--r--   1 ken 100    220 May 12  2014 BRANCH_DESCRIPTION
drwxr-xr-x   2 ken 100   4096 Apr 13  2010 branches
-rw-r--r--   1 ken 100    470 Mar  8 16:08 COMMIT_EDITMSG
-rw-r--r--   1 ken 100    566 May 17  2014 config
-rw-r--r--   1 ken 100     73 May  1  2010 description
-rw-r--r--   1 ken 100 196439 Sep 17 21:56 gitk.cache
-rw-rw-rw-   1 ken 100     29 Feb  8 22:19 HEAD
drwxr-xr-x   2 ken 100   4096 May  1  2010 hooks
-rw-r--r--   1 ken 100 218255 Mar  8 16:07 index
drwxr-xr-x   2 ken 100   4096 Sep 16  2013 info
drwxr-xr-x   3 ken 100   4096 Sep 16  2013 logs
drwxr-xr-x 260 ken 100   4096 Nov 12  2013 objects
-rw-r--r--   1 ken 100     41 Nov 11 06:05 ORIG_HEAD
-rw-r--r--   1 ken 100   1879 Sep 16  2013 packed-refs
drwxr-xr-x   5 ken 100   4096 May 20  2014 refs
-rw-r--r--   1 ken 100     41 Dec  7  2010 RENAMED-REF

Running git blame on a script which dates back to when the repo was
created takes between 5 and 6 seconds to show the first screen,
running it on a file first created last August took about 3 seconds.
I have another small repo also on nfs with only a few files, started
last year, and there git blame takes about a second.

In my clone of linus' tree, running git blame scripts/headers.sh (a
random example,I do not normally run git blame there) took 10
seconds to return the first screen.

All of those timings are from preparing the comand, watching my
desktop clock until it changes the second, and hitting enter - so,
only accurate to approx one second.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.