From: Linus Torvalds Date: Tue, 26 Apr 2005 04:20:12 GMT Subject: Re: Mercurial 0.3 vs git benchmarks Message-ID: 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. > > 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