5 ms·

"It's the speed of Git..." No it's not. Speaking from experience here. Edit: Okay, here's some real data: http://git.or.cz/gitwiki/GitBenchmarks http://git.or

"It's the speed of Git..." No it's not. Speaking from experience here. Edit: Okay, here's some real data: http://git.or.cz/gitwiki/GitBenchmarks http://git.or.cz/gitwiki/GitBenchmarks http://whygitisbetterthanx.com/#git-is-fast http://whygitisbetterthanx.com/#git-is-fast It shows that git wins by most metrics, with a few exceptions. Mercurial's push/pull format is particularly good.

davidw 17y ago
What sort of hit? Is it just a bit pokier or does it get really bad for anything in particular? Anyone got any actual data?
- axod 17y ago
  >> "Anyone got any actual data?" Is the SPEED of any revision control system ever an issue? To anyone? Surely it's 'fast enough that it doesn't matter' vs 'fast enough that it doesn't matter'
  - masklinn 17y ago
    > Is the SPEED of any revision control system ever an issue? Yes, darcs used to have (and probably still has, though to a lesser level) an issue with merge times blowing up exponentially. Anyway stevejohnson took issue with the statement that Mercurial performed roughly on part with Git, you might want to take the issue up to him not davidw.
  - rictic 17y ago
    I'm not sure about git vs hg, but I'd definitely say that the speed of git is a win vs svn. For example, running status to see the state of the working directory. With svn it takes a couple of seconds on small repositories, and it can easily climb above ten seconds on larger repos. With git it very rarely rises above a second, even with a cold disk cache. The difference in speed is large enough that I find myself running "git status" far, far more often than I ever ran "svn status". A more dramatic example is 'git bisect' which, when given a command, it will do a binary search on the repository to find the commit which caused that command to begin to fail (return an exit code of something other than 0). Speed is a feature.
  - dlsspy 17y ago
    Yes, when a command takes a couple seconds to perform, you don't consider doing it unless you have a really good reason. Classic hg branching came into different forms: 1) a tree clone and 2) the hg "branch" commands. 1 can be very slow on a large tree and can often require you reconfigure your tools to go look in a new place. 2 is permanent. Your code now forever references the name of a branch so you have to stop and think about whether it's really the right thing to do. In either case, anything that requires me to stop and consider the cost of an operation makes the operation less valuable. Where that cost kicks in varies for people. Is it minutes? Seconds? As a former perforce user, there were definitely plenty of things I wouldn't do there because they weren't instant. In git, I tend to make decisions based solely on my desired outcome.
gecko 17y ago
Speaking from my own experience, we're talking about, at most, maybe a 5% speed penalty in some operations; most others happen instantly on both systems. Can you provide a concrete example where Mercurial's noticeably slower than Git at the same operation? Edit in response to above edit: those stats are for Mercurial 0.4 through 0.9.5. The current version is Mercurial 1.3.1. Seeing as there have been piles of speedups, including several that fell out from Python modules getting rewritten in C, I find that page highly dubious.

davidw 17y ago

What sort of hit? Is it just a bit pokier or does it get really bad for anything in particular? Anyone got any actual data?

axod 17y ago
>> "Anyone got any actual data?" Is the SPEED of any revision control system ever an issue? To anyone? Surely it's 'fast enough that it doesn't matter' vs 'fast enough that it doesn't matter'
- masklinn 17y ago
  > Is the SPEED of any revision control system ever an issue? Yes, darcs used to have (and probably still has, though to a lesser level) an issue with merge times blowing up exponentially. Anyway stevejohnson took issue with the statement that Mercurial performed roughly on part with Git, you might want to take the issue up to him not davidw.
- rictic 17y ago
  I'm not sure about git vs hg, but I'd definitely say that the speed of git is a win vs svn. For example, running status to see the state of the working directory. With svn it takes a couple of seconds on small repositories, and it can easily climb above ten seconds on larger repos. With git it very rarely rises above a second, even with a cold disk cache. The difference in speed is large enough that I find myself running "git status" far, far more often than I ever ran "svn status". A more dramatic example is 'git bisect' which, when given a command, it will do a binary search on the repository to find the commit which caused that command to begin to fail (return an exit code of something other than 0). Speed is a feature.
- dlsspy 17y ago
  Yes, when a command takes a couple seconds to perform, you don't consider doing it unless you have a really good reason. Classic hg branching came into different forms: 1) a tree clone and 2) the hg "branch" commands. 1 can be very slow on a large tree and can often require you reconfigure your tools to go look in a new place. 2 is permanent. Your code now forever references the name of a branch so you have to stop and think about whether it's really the right thing to do. In either case, anything that requires me to stop and consider the cost of an operation makes the operation less valuable. Where that cost kicks in varies for people. Is it minutes? Seconds? As a former perforce user, there were definitely plenty of things I wouldn't do there because they weren't instant. In git, I tend to make decisions based solely on my desired outcome.

gecko 17y ago

Speaking from my own experience, we're talking about, at most, maybe a 5% speed penalty in some operations; most others happen instantly on both systems. Can you provide a concrete example where Mercurial's noticeably slower than Git at the same operation? Edit in response to above edit: those stats are for Mercurial 0.4 through 0.9.5. The current version is Mercurial 1.3.1. Seeing as there have been piles of speedups, including several that fell out from Python modules getting rewritten in C, I find that page highly dubious.