git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Performance issue of 'git branch'

From
Linus Torvalds <torvalds@linux-foundation.org>
Date
Jul 23, 2009, 00:21 UTC
Message-ID
<alpine.LFD.2.01.0907221714300.3352@localhost.localdomain>
In-Reply-To
<20090722235914.GA13150@Pilar.aei.mpg.de>
On Thu, 23 Jul 2009, Carlos R. Mafra wrote:
Show 19 quoted lines
> 
> When I run 'git branch' in the linux-2.6 repo I think it takes
> too long to finish (with cold cache):
> 
> [mafra@Pilar:linux-2.6]$ time git branch
>   27-stable
>   28-stable
>   29-stable
>   30-stable
>   dev-private
> * master
>   option
>   sparse
>   stern
> 0.00user 0.05system 0:05.73elapsed 1%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (209major+1380minor)pagefaults 0swaps
> 
> This is with git 1.6.4.rc1.10.g2a67 and the kernel is 2.6.31-rc3+. The
> machine is a 64bit Vaio laptop which is 1+ year old (so it is not "slow").
When have you last repacked the repository?

What you're descibing is basically IO overhead, and if you don't have packed references, it's going to read a lot of small files.

Show 24 quoted lines
> I use git to track linux-2.6 for 2 years now, and I remember that
> 'git branch' is slow for quite some time, so it is not a regression
> or something. It is just now that I took the courage to report this
> small issue.
> 
> I did a 'strace' and this is where it spent most of the time:
> 
> 1248301060.654911 open(".git/refs/heads/sparse", O_RDONLY) = 6
> 1248301060.654985 read(6, "60afdf6a4065a170ad829b4d79a86ec0"..., 255) = 41
> 1248301060.655056 read(6, "", 214)      = 0
> 1248301060.655116 close(6)              = 0
> 1248301060.680754 lstat(".git/refs/heads/stern", 0x7fff80bfa8d0) = -1 ENOENT (No such file or directory)
> 1248301064.018491 fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
> 1248301064.018641 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f409ffa7000
> 1248301064.018722 write(1, "  27-stable\33[m\n", 15) = 15
> 
> I don't know why .git/refs/heads/stern does not exist and why it takes
> so long with it. That branch is functional ('git checkout stern' succeeds),
> as well as all the others. But strangely .git/refs/heads/ contains only
> 
> [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.

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. And your filesystem doesn't have name hashing enabled, so searching for a non-existent file involves looking through _all_ of the empty slots.

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.
			Linus
Previous: Carlos R. MafraNext: Linus Torvalds
Message 2 of 73 in “Performance issue of 'git branch'”
  1. Carlos R. MafraJul 22, 2009
  2. Linus TorvaldsJul 23, 2009
  3. Linus TorvaldsJul 23, 2009
  4. Linus TorvaldsJul 23, 2009
  5. Carlos R. MafraJul 23, 2009
  6. Linus TorvaldsJul 23, 2009
  7. Jakub NarebskiJul 23, 2009
  8. Carlos R. MafraJul 23, 2009
  9. Linus TorvaldsJul 23, 2009
  10. Carlos R. MafraJul 23, 2009
  11. Linus TorvaldsJul 23, 2009
  12. Linus TorvaldsJul 23, 2009
  13. Linus TorvaldsJul 23, 2009
  14. Linus TorvaldsJul 23, 2009
  15. Tony FinchJul 23, 2009
  16. Linus TorvaldsJul 23, 2009
  17. Newton-Raphson, was Re: Performance issue of 'git branch'Tony Finch, Jul 23, 2009
  18. Johannes SchindelinJul 23, 2009
  19. Tony FinchJul 23, 2009
  20. Johannes SchindelinJul 24, 2009
  21. Carlos R. MafraJul 23, 2009
  22. Carlos R. MafraJul 23, 2009
  23. Carlos R. MafraJul 23, 2009
  24. Linus TorvaldsJul 23, 2009
  25. Linus TorvaldsJul 23, 2009
  26. Junio C HamanoJul 23, 2009
  27. Carlos R. MafraJul 23, 2009
  28. Junio C HamanoJul 23, 2009
  29. Linus TorvaldsJul 23, 2009
  30. Junio C HamanoJul 23, 2009
  31. Junio C HamanoJul 23, 2009
  32. Linus TorvaldsJul 23, 2009
  33. Carlos R. MafraJul 23, 2009
  34. Linus TorvaldsJul 23, 2009
  35. Carlos R. MafraJul 23, 2009
  36. Linus TorvaldsJul 23, 2009
  37. Linus TorvaldsJul 23, 2009
  38. Carlos R. MafraJul 23, 2009
  39. Linus TorvaldsJul 24, 2009
  40. Linus TorvaldsJul 24, 2009
  41. Linus TorvaldsJul 24, 2009
  42. Linus TorvaldsJul 24, 2009
  43. david@lang.hmJul 24, 2009
  44. Linus TorvaldsJul 24, 2009
  45. david@lang.hmJul 24, 2009
  46. Linus TorvaldsJul 25, 2009
  47. Daniel BarkalowJul 25, 2009
  48. Jeff KingAug 7, 2009
  49. Theodore TsoJul 24, 2009
  50. Shawn O. PearceJul 24, 2009
  51. Junio C HamanoJul 24, 2009
  52. Avi KivityJul 26, 2009
  53. Johannes SchindelinJul 26, 2009
  54. Carlos R. MafraJul 24, 2009
  55. Carlos R. MafraJul 25, 2009
  56. Linus TorvaldsJul 25, 2009
  57. Timo HirvonenJul 25, 2009
  58. Reece DunnJul 25, 2009
  59. Mike HommeyJul 25, 2009
  60. Linus TorvaldsJul 25, 2009
  61. Linus TorvaldsJul 25, 2009
  62. Johannes SchindelinJul 25, 2009
  63. Linus TorvaldsJul 26, 2009
  64. Theodore TsoJul 26, 2009
  65. Mike HommeyJul 26, 2009
  66. Johannes SchindelinJul 26, 2009
  67. demerphqJul 26, 2009
  68. demerphqJul 26, 2009
  69. Carlos R. MafraJul 25, 2009
  70. Anders KaseorgJul 23, 2009
  71. Carlos R. MafraJul 23, 2009
  72. SZEDER GáborJul 23, 2009
  73. Carlos R. MafraJul 23, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.