Re: Performance issue of 'git branch'
From: Carlos R. Mafra <hidden>
Date: 2016-06-15 22:47:05
On Wed 22.Jul'09 at 17:21:48 -0700, Linus Torvalds wrote:
When have you last repacked the repository?
Last week or so, with 'git repack -d -a'
quoted
[mafra@Pilar:linux-2.6]$ ls .git/refs/heads/ dev-private master sparse which, apart from "master", are the last branches that I created.Ok, this actually means that you _have_ repacked the repo, and the rest of the branches are all nicely packed in .git/packed-refs.
Yes, now I saw the other branches inside packed-refs.
But that four _second_ lstat() is really disgusting. Let me guess: if you do a "ls -ld .git/refs/heads" you get a very big directory, despite it only having three entries in it.
[mafra@Pilar:linux-2.6]$ ls -ld .git/refs/heads drwxr-xr-x 2 mafra mafra 4096 2009-07-22 23:01 .git/refs/heads/
And your filesystem doesn't have name hashing enabled, so searching for a non-existent file involves looking through _all_ of the empty slots.
I use ext3 without changing any defaults that I know of (I simply compile and boot the kernel of the day), and I have no idea if name hashing is enabled here.
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.
It didn't change things, unfortunately.
After 'echo 3 > /proc/sys/vm/drop_caches' it still takes too long,
1248310449.693085 munmap(0x7f50bcd11000, 164) = 0
1248310449.693187 lstat(".git/refs/heads/sparse", 0x7fff618c0960) = -1 ENOENT (No such file or directory)
1248310449.719112 lstat(".git/refs/heads/stern", 0x7fff618c0960) = -1 ENOENT (No such file or directory)
1248310453.014041 fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 3), ...}) = 0
1248310453.014183 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f50bcd11000
Perhaps I should delete the "stern" branch, but I would like to learn why
it is slowing things, because it also happened before (in fact it is always
like this, afaicr)
Do you have another theory? (now .git/refs/heads is empty)
Thanks,
Carlos