git vs mercurial performance

Do any performance benchmarks exist?

I'm looking to create a repo and commit/ push for legacy code that runs several gigs deep.

Is either faster / footprint etc?

I apologize if this i开发者_运维知识库s too vague...

You don't choose between git and mercurial because of performance. They're both good.

Just do the kinds of things you'd be doing and measure. You're likely to get the largest performance variation on the first import -- that won't matter much. Keep digging.

Space-wise, the one place git will definitely win is if you have the same content in lots of different paths in its lifetime. That is, if your several gigs of files get moved. git's model supports this better than hg's. That very well may not matter to you.

In both cases, you should consider whether your several gigs of repository actually represents the source code for a single project.

But again, it would be unwise to choose between these two similar and active projects because of raw performance.

There was a recent (January 2011) performance comparison between Mercurial and Git server performance. The conclusion is that Mercurial gives a more steady performance than Git, but that Git is faster on average.

Original Answer (March 2011, GitHub had less than 3 years)

The correct performance to measure about a DVCS (which performs all operations locally anyway) is the one about your daily tasks:

• merge (how quickly do you decide between the various branching models, especially in Mercurial?)
• publication workflow (how quickly do you setup one push/pull worlflow?)
• integration (how quickly do you integrate Git with IDE, with webapp like Hudson or Jira or Redmine or Track, or ...?)
• setup (how quickly do you setup a centralized repository, with what kind of authentication mechanism: that matters if you use a DVCS in an enterprise environment)

The raw performance of basic operations isn't that relevant, provided you understand the limits of a DVCS: you cannot have one single repo into which you would put everything (all projects, or all kind of files like binaries).
Some kind of modules reorganization must take place to define the right amount of repo per "modules" (coherent file sets).

Update 2018, seven years later: The Windows support for Git is now a reality, and aim at improving perfomance/scalability of Git.

To illustrate that, Microsoft has its entire Windows codebase into one (giant) Git repository: See "The largest Git repo on the planet": 3.5M files, 300GB, 4,000 engineers producing 1,760 daily “lab builds” across 440 branches in addition to thousands of pull request validation builds.
But this is with the addition of GVFS (Git Virtual FileSystem), which allows to dynamically download only the portions you need based on what you use.
This is not yet in Git native, although its integration has begun last Dec. 2017, with the implementation of a narrow/partial cloning.

As pointed out @MartinGeisler in his answer, the commit time is very small (if you commit through command-line, you shell returns immediately).

What takes quite long are the network clones/pushes/pulls. Google published small benchmark (see footnote 1) when they had to choose a DVCS for Google code, but it is quite old (summer 2008).

Eric Sink has published the results of a benchmark for SVN, Bazar, Mercurial, Git and his own Veracity.

Unfortunately it's just a single operation (a commit), with a single code base (Valgrind), and I am not sure which version he used for all these VCS's but in any case it must be pretty old as the article dates back to 2011. I guess this is why Eric himself defines them "Ridiculously Unscientific Benchmarks". Anyway, for what it's worth:

SVN is much slower than the others (almost 22 seconds), but all the others are similar (between 3 and 5 seconds). Git is clearly the fastest, and in percentage it's even much faster than Mercurial (which takes 43% more time), but actually we are talking about a difference of 1.4 seconds - hardly noticeable.

Apart from this, I can't find the sources right now, but I've read several times that Git is faster, though the difference is trivial (which confirms this test made by Eric). So I wouldn't worry too much about speed when choosing which one to go with.