Re: Mercurial 0.3 vs git benchmarks

[Chris Mason <mason@suse.com>]

On Tuesday 26 April 2005 12:42, Linus Torvalds wrote:
> On Tue, 26 Apr 2005, Chris Mason wrote:
> > This agrees with my tests here, the time to apply patches is somewhat
> > disk bound, even for the small 100 or 200 patch series.  The io should be
> > coming from data=ordered, since the commits are still every 5 seconds or
> > so.
>
> Yes, ext3 really does suck in many ways.
>
> One of my (least) favourite suckage is a process that does "fsync" on a
> single file (mail readers etc), which apparently causes ext3 to sync all
> dirty data, because it can only sync the whole log. So if you have stuff
> that writes out things that aren't critical, it negatively affects
> something totally independent that _does_ care.
>
> I remember some early stuff showing that reiserfs was _much_ better for
> BK. I'd be willing to bet that's probably true for git too.

reiserfs shares the same basic data=ordered idea as ext3, so the fsync will do 
the same on reiser as it does on ext3.  I do have code in there to try and 
keep the data=ordered writeback a little less bursty than it is in ext3 so 
you might not notice the fsync as much.

I haven't compared reiser vs ext3 for git.  reiser tails should help 
performance because once you read the object inode you've also got the data.  
But, I would expect the biggest help to come from mounting reiserfs -o 
alloc=skip_busy.  This basically allocates all new files one right after the 
other on disk regardless of which subdir they are in.  The effect is to time 
order most of your files.

As an example, here's the time to apply 300 patches on ext3.  This was with my 
packed patches applied, but vanilla git should show similar percentage 
differences.

data=writeback  32s			
data=ordered    44s

With a long enough test, data=ordered should fall into the noise, but 10-40 
second runs really show it.

-chris