Re: Performance issue of 'git branch'
- From
Linus Torvalds <torvalds@linux-foundation.org>
- Date
- Jul 23, 2009, 00:51 UTC
- Message-ID
- <alpine.LFD.2.01.0907221742010.3352@localhost.localdomain>
- In-Reply-To
- <alpine.LFD.2.01.0907221714300.3352@localhost.localdomain>
On Wed, 22 Jul 2009, Linus Torvalds wrote:
Show 12 quoted lines
> > Try this: > > git pack-refs --all > > rmdir .git/refs/heads > rmdir .git/refs/tags > > mkdir .git/refs/heads > mkdir .git/refs/tags > > and see if it magically speeds up.
In fact, you could also just try
mv .git/refs .git/temp-refs && cp -a .git/temp-refs .git/refs && rm -rf .git/temp-refs
which will re-create other subdirectories too (like .git/refs/remotes etc).
Of course, depending on your particular filesystem, a better fix might be to enable filename hashing, which gets rid of the whole "look through all the old empty stale directory entries to see if there's a filename there" issue. That won't fix 'readdir()' performance, but it should fix your insane 4-second lstat() thing.
If you have ext3, you'd do something like
tune2fs -O dir_index /dev/<node-of-your-filesystem-goes-here>
but as mentioned, even with directory indexing it can actually make sense to recreate directories that at some point _used_ to be large, but got shrunk down to something much smaller. It's a generic directory problem (not just ext3, not just unix, it's a common issue across filesystems. It's not _universal_ - some smarter filesystems really do shrink their directories - but it's certainly not unusual).
Linus