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

Re: Why Git is so fast (was: Re: Eric Sink's blog - notes on git, dscms and a "whole product" approach)

From
Daniel Barkalow <barkalow@iabervon.org>
Date
May 1, 2009, 21:17 UTC
Message-ID
<alpine.LNX.2.00.0905011618370.2147@iabervon.org>
In-Reply-To
<20090501190854.GA13770@coredump.intra.peff.net>
On Fri, 1 May 2009, Jeff King wrote:
Show 27 quoted lines
> On Fri, May 01, 2009 at 02:43:49PM -0400, Linus Torvalds wrote:
> 
> > > Like all generalizations, this is only mostly true. Fast network servers
> > > with big caches can outperform disks for some loads.
> > [...]
> > In contrast, a workstation with local filesystems and enough memory to 
> > cache it well will just be a lot nicer.
> > [...]
> > > I have never used perforce, but I get the impression that it is more 
> > > optimized for such a situation.
> > 
> > I doubt it. I suspect git will outperform pretty much anything else in 
> > that kind of situation too.
> 
> Thanks for the analysis; what you said makes sense to me. However, there
> is at least one case of somebody complaining that git doesn't scale as
> well as perforce for their load:
> 
>   http://gandolf.homelinux.org/blog/index.php?id=50
> 
> Part of his issue is with git-p4 sucking, which it probably does. But
> part of it sounds like he has a gigantic workload (the description of
> which sounds silly to me, but I respect the fact that he is probably
> describing standard practice among some companies), and that workload is
> just a little too gigantic for the workstations to handle. I.e., by
> throwing resources at the central server they can avoid throwing as many
> at each workstation.

I think his problem is that he's trying to replace his p4 repository with a git repository, which is a bit like trying to download github, rather than a project from github. Perforce is good at dealing with the case where people check in a vast quantity of junk that you don't check out.

That is, you can back up your workstation into Perforce, and it won't affect anyone's performance if you use a path that's not in the range that anybody else checks out. And people actually do that. And Perforce doesn't make a distinction between different projects and different branches of the same project and different subdirectories of a branch of the same project, so it's impossible to tease apart except by company policy.

Git doesn't scale in that it can't do the extremely narrow checkouts you need if your repository root directory contains thousands of complete unrelated projects with each branch of each project getting a subdirectory. On the other hand, it does a great job when the data is already partitioned into useful repositories.

	-Daniel
*This .sig left intentionally blank*
Previous: Nicolas PitreNext: Linus Torvalds
Message 33 of 39 in “Eric Sink's blog - notes on git, dscms and a "whole product" approach”
  1. Martin LanghoffApr 27, 2009
  2. Cross-Platform Version Control (was: Eric Sink's blog - notes on git, dscms and a "whole product" approach)Jakub Narebski, Apr 28, 2009
  3. Robin RosenbergApr 28, 2009
  4. Martin LanghoffApr 29, 2009
  5. Jeff KingApr 29, 2009
  6. Markus HeidelbergApr 29, 2009
  7. Jakub NarebskiApr 29, 2009
  8. Martin LanghoffApr 29, 2009
  9. Jakub NarebskiApr 28, 2009
  10. Sitaram ChamartyApr 29, 2009
  11. Why Git is so fast (was: Re: Eric Sink's blog - notes on git, dscms and a "whole product" approach)Jakub Narebski, Apr 30, 2009
  12. Michael WittenApr 30, 2009
  13. Jakub NarebskiApr 30, 2009
  14. Shawn O. PearceApr 30, 2009
  15. Kjetil BarvikApr 30, 2009
  16. Shawn O. PearceApr 30, 2009
  17. Kjetil BarvikApr 30, 2009
  18. Steven NoonanMay 1, 2009
  19. James PickensMay 1, 2009
  20. Kjetil BarvikMay 1, 2009
  21. Mike HommeyMay 1, 2009
  22. Kjetil BarvikMay 1, 2009
  23. Tony FinchMay 1, 2009
  24. Dmitry PotapovMay 1, 2009
  25. Mike HommeyMay 1, 2009
  26. Dmitry PotapovMay 1, 2009
  27. Shawn O. PearceApr 30, 2009
  28. Jeff KingApr 30, 2009
  29. Linus TorvaldsMay 1, 2009
  30. Jeff KingMay 1, 2009
  31. david@lang.hmMay 1, 2009
  32. Nicolas PitreMay 1, 2009
  33. Daniel BarkalowMay 1, 2009
  34. Linus TorvaldsMay 1, 2009
  35. david@lang.hmMay 1, 2009
  36. Nicolas PitreApr 30, 2009
  37. Alex RiesenApr 30, 2009
  38. Andreas EricssonMay 4, 2009
  39. Jakub NarebskiApr 30, 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.