__git_ps1 extremely slow in kernel tree

Question

$ time __git_ps1
((v2.6.33.4))
real    0m1.467s
user    0m0.864s
sys  0m0.564s

It's making my prompt unusable; on the other hand, though, it's too useful a feature to give up lightly. Any idea why it runs so slow and what I can do about it?

Setup details:

$ uname -a
Linux martin-laptop 2.6.35-22-generic #35-Ubuntu SMP Sat Oct 16 20:36:48 UTC 2010 i686 GNU/Linux

$ git --version
git version 1.7.1

$ du -sh .
876M    .

I suspect something with my machine since on my coworker's box, in the kernel tree I cloned from, the same command returns instantly

$ time __git_ps1
((v2.6.33.4))
real    0m0.039s
user    0m0.008s
sys 0m0.016s

adding hdparm output:

mine

$ sudo hdparm -tT /dev/sda4

/dev/sda4:
 Timing cached reads:   1542 MB in  2.00 seconds = 772.35 MB/sec
 Timing buffered disk reads:  110 MB in  3.02 seconds =  36.42 MB/sec

coworker's

$ sudo hdparm -Tt /dev/sda6

/dev/sda6:
 Timing cached reads:   1850 MB in  2.00 seconds = 926.03 MB/sec
 Timing buffered disk reads:  210 MB in  3.02 seconds =  69.53 MB/sec

other differences: coworker is running git 1.6.5, i'm running 1.7.1

What operating system are you running? How large is your repository? — Greg Hewgill, Nov 16 '10 at 07:35
is it slow only the first time, or are subsequent calls to `__git_ps1` respectively `git status` slow too? could be a caching issue. (on my pc the first call is really slow, after that it's fast) — knittl, Nov 16 '10 at 08:13
can you also provide details of hdparm -tT from yours and coworker PC ? if they are equal you can try to use top (or any other activity monitor) to see if there is no process that kills yours machine performance ? — mpapis, Nov 16 '10 at 08:15
mpapis: added hdparm output, not significantly different. top shows the cpu idling along at 10% — Martin DeMello, Nov 16 '10 at 08:51
your colleagues buffered reads are twice as fast (read twice as much in the same time) — knittl, Nov 16 '10 at 09:23
looks like You need to check you harddisk, maybe getting new disk/machine could help you — mpapis, Nov 17 '10 at 11:12
@mpapis yeah, looks that way. i did manage to fix the __git_ps1 problem at least, though git status/diff is still annoyingly slow. (since this is an otherwise-working office machine, i doubt i'll be getting a new one any time soon, sadly :)) — Martin DeMello, Nov 17 '10 at 11:41

score 23 · Accepted Answer · answered Nov 17 '10 at 11:39

23

It turned out to be a combination of two things:

I was using

export GIT_PS1_SHOWDIRTYSTATE=true
export GIT_PS1_SHOWUNTRACKEDFILES=true

by default. which proved to be unusable on a tree the size of the kernel. Removing these options removes a bit of nice functionality from __git_ps1, but at least it returns instantly now. (Useful lesson - try out stuff from a freshly created user account before anything else.)

Also, the hard disk on my work machine is just plain slow, so that wasn't a git problem per se; it's just the first time it really obtruded itself upon my notice.

answered Nov 17 '10 at 11:39

Martin DeMello

11,876
7
49
64

5

you can use `git config --global bash.showDirtyState true` and override this for the kernel tree only with `git config bash.showDirtyState false`. There is no setting like this for untracked files (on git 1.7.3.2) but it should be easy to implement that as well – Tobias Kienzler Jan 20 '11 at 14:05
+1: This turned out to be the reason for my command prompt's sluggishness even when working with rather small repositories. – Dan Moulding Oct 26 '11 at 14:58

nicolas · Answer 2 · 2022-02-21T14:00:12.690

9

to know where exactly this takes time you can do :

bash -x

then

__git_ps1

Mine was taking time for

++ git ls-files --others --exclude-standard

it was listing all the files of my gitted home drectory. even on a fast ssd, it took quite a long time.

To get a full log, you do from a shell

zsh -x 2> zshdebug.log

then you exit that subshell, the debug info is in the zshdebug.log file

edited Feb 21 '22 at 14:00

answered Feb 22 '11 at 09:06

nicolas

9,549
3
39
83

1

nice tip, thanks! turns out the same thing is taking time for me. – Martin DeMello Feb 22 '11 at 10:58

score 5 · Answer 3 · answered Apr 24 '13 at 18:41

5

To fix this just add this in your .bashrc

export GIT_PS1_SHOWDIRTYSTATE=
export GIT_PS1_SHOWUNTRACKEDFILES=

Will disable some files look-ups.

answered Apr 24 '13 at 18:41

Felipe Tonello

290
3
11

score 3 · Answer 4 · answered Nov 16 '10 at 15:57

3

Does the repo have submodules? See the remark regarding "git status is now very slow" (with submodules) in this post, due to a change introduced in 1.7.0:

The fix/work-around is to pass "--ignore-submodules" to "git status", as noted in the update below the section: "Update: Thanks to VonC, who points out in the comments below that in git 1.7.2 there is now a “–ignore-submodules” option to git status which can restore the old behaviour and also provides the useful option that only changed files (not untracked files) cause the submodule to be shown as dirty."

answered Nov 16 '10 at 15:57

Jeet

38,594
7
49
56

The full kernel tree certainly does have submodules. – Cascabel Nov 16 '10 at 16:48
upgraded to 1.7.3 and tried out --ignore-submodules, but it didn't help. giving 1.6.6 a try now. – Martin DeMello Nov 16 '10 at 17:57

score 1 · Answer 5 · answered Nov 16 '10 at 07:47

1

could you try my version of git PS1 is it faster or equally slow ?

answered Nov 16 '10 at 07:47

mpapis

52,729
14
121
158

it's even slower. i'm suspecting something with git in general at this point, since git status too is taking way longer than it should – Martin DeMello Nov 16 '10 at 07:54

Fredrik Pihl · Answer 6 · 2010-11-16T14:54:14.513

1

how about updating git-completion.bash to the latest from http://git.kernel.org/?p=git/git.git;a=tree;f=contrib/completion;h=525eddf7e4c03acc7b3f01f09f45515cf63cd9b4;hb=master

Is the problem local to this kernel repo or general?

Does git fsck --full reveal anything?

edited Nov 16 '10 at 14:54

answered Nov 16 '10 at 14:25

Fredrik Pihl

44,604
7
83
130

latest git-completion.bash didn't help. it also seems to be local to the kernel, but i have nothing else of comparable size to test it with. will leave git fsck --full running when i leave and see if it has turned up anything in the morning, though i think the repo is fine since it's a clone from the working repo on my coworker's box. – Martin DeMello Nov 16 '10 at 17:56
and git fsck --full didn't find any problems either. – Martin DeMello Nov 17 '10 at 06:16
2

clone a kernel repo from kernel.org and see if the problem is present there as well. If that one is ok, your old repo probably is broken in some strange way. Another approach is to use "strace" on git status to see what is happening. Perhaps a diff with the strace output on your colleges machine. – Fredrik Pihl Nov 17 '10 at 08:28
happens with a fresh kernel clone too. the strace is a nice idea, will give it a shot. at this point i'm beginning to suspect i just have a crappy hard disk. – Martin DeMello Nov 17 '10 at 10:50

__git_ps1 extremely slow in kernel tree

6 Answers6

Linked