Re: Mercurial 0.3 vs git benchmarks

Linus Torvalds
2005-04-26T04:18:28Z

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.

> > 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