Re: Mercurial 0.3 vs git benchmarks
- From
Linus Torvalds <torvalds@osdl.org>
- Date
- Apr 26, 2005, 04:20 UTC
- Message-ID
- <Pine.LNX.4.58.0504252113210.18901@ppc970.osdl.org>
- In-Reply-To
- <20050426040127.GK21897@waste.org>
On Mon, 25 Apr 2005, Matt Mackall wrote:
> > And the number of files checked in grows from ~1000 to ~6000. Note > that git is growing from 4 to 19 seconds as well.
Heh,. I didn't much look at the git numbers, since I knew those were supposed to be linear in the size of the patch...
> I'm not versant enough with git enough to know how but I'll give it a > shot. Do you have the patches in an mbox, perchance? This is Andrew's > x/198 patch bomb?
Yes. I have my "tools" scripts for git in
kernel.org:/pub/linux/kernel/people/torvalds/git-tools.git
and I sent out the script I used to test the 2.6.12-rc2 + patches stuff in the previous email, so you would just have to edit my mbox-applicator tools to work with hg and get comparable numbers.
> It might be simpler for me to just apply everything > in -mm to git and hg and compare times.
That should work.
Show 6 quoted lines
> > You're doing something wrong with git here. Why would you need to update > > your cache? > > Quite possibly. Without it, I was getting a dump of a bunch of SHAs. > I'm pretty git-ignorant, I've been focusing on something else for the > past couple weeks.
Getting a bunch of SHA's means that the file contents match, but that your index file wasn't up-to-date, so git had to actually uncompress the object backing store and _compare_ the file contents to notice.
And I suspect that you may have done _all_ your numbers without ever having initialized the git index, in which case git will really suck raw eggs, because git will basically always re-read every file (it will never realize that they are up-to-date already).
Basically, the theory of git operation is that the index file should _always_ be up-to-date. Normally you don't have to do anything about it, since the git helper tools will always just keep it that way, but if you didn't, then..
Linus