From: Linus Torvalds <torvalds@osdl.org>
To: Mike Taht <mike.taht@timesys.com>
Cc: Matt Mackall <mpm@selenic.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
git@vger.kernel.org
Subject: Re: Mercurial 0.3 vs git benchmarks
Date: Mon, 25 Apr 2005 21:00:05 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.58.0504252032500.18901@ppc970.osdl.org> (raw)
In-Reply-To: <Pine.LNX.4.58.0504251938210.18901@ppc970.osdl.org>
On Mon, 25 Apr 2005, Linus Torvalds wrote:
>
> The easiest test-case is Andrew's 198-patch patch-bomb on linux-kernel a
> few weeks ago: they all apply cleanly to 2.6.12-rc2 (in order), and you
> can use my "dotest" script to automate the test..
Oh, well. That was so trivial that I just did it:
With Z_BEST_COMPRESSION:
torvalds@ppc970:~/git-speed-1> ./script
Removing old tree
Creating new tree
Initializing db
defaulting to local storage area
Doing sync
Initial add
real 0m37.526s
user 0m33.317s
sys 0m3.816s
Initial commit
Committing initial tree 0bba044c4ce775e45a88a51686b5d9f90697ea9d
real 0m0.329s
user 0m0.152s
sys 0m0.176s
Patchbomb
real 0m50.408s
user 0m18.933s
sys 0m25.432s
With Z_DEFAULT_COMPRESSION:
torvalds@ppc970:~/git-speed-1> ./script
Removing old tree
Creating new tree
Initializing db
defaulting to local storage area
Doing sync
Initial add
real 0m19.755s
user 0m15.719s
sys 0m3.756s
Initial commit
Committing initial tree 0bba044c4ce775e45a88a51686b5d9f90697ea9d
real 0m0.337s
user 0m0.139s
sys 0m0.197s
Patchbomb
real 0m50.465s
user 0m18.304s
sys 0m25.567s
ie the "initial add" is almost twice as fast (because it spends most of
the time compressing _all_ the files), but the difference in applying 198
patches is not noticeable at all (because the costs are all elsewhere).
That's 198 patches in less than a minute even with the highest
compression. That rocks.
And don't try to make me explain why the patchbomb has any IO time at all,
it should all have fit in the cache, but I think the writeback logic
kicked in. Anyway, I tried it several times, and the real-time ends up
fluctuating between 50-56 seconds, but the user/sys times are very stable,
and end up being pretty much the same regardless of compression level.
Here's the script, in case anybody cares:
#!/bin/sh
echo Removing old tree
rm -rf linux-2.6.12-rc2
echo Creating new tree
zcat < ~/v2.6/linux-2.6.12-rc2.tar.gz | tar xvf - > log
echo Initializing db
( cd linux-2.6.12-rc2 ; init-db )
echo Doing sync
sync
echo Initial add
time sh -c 'cd linux-2.6.12-rc2 && cat ../l | xargs update-cache --add --' >> log
echo Initial commit
time sh -c 'cd linux-2.6.12-rc2 && echo Initial commit | commit-tree
$(write-tree) > .git/HEAD' >> log
echo Patchbomb
time sh -c 'cd linux-2.6.12-rc2 ; dotest ~/andrews-first-patchbomb' >> log
and since the timing results were pretty much what I expected, I don't
think this changes _my_ opinion on anything. Yes, you can speed up commits
with Z_DEFAULT_COMPRESSION, but it's _not_ that big of a deal for my kind
of model where you commit often, and commits are small.
It all boils down to:
- huge commits are slowed down by compression overhead
- I don't think huge commits really matter
I mean, if it took 2 _hours_ to do the initial commit, I'd think it
matters. But when we're talking about less than a minute to create the
initial commit of a whole kernel archive, does it really make any
difference?
After all, it's something you do _once_, and never again (unless you
script it to do performance testing ;)
Anyway guys, feel free to test this on other machines. I bet there are
lots of subtle performance differences between different filesystems and
CPU architectures.. But the only hard numbers I have show that -9 isn't
that expensive.
Linus
next prev parent reply other threads:[~2005-04-26 3:59 UTC|newest]
Thread overview: 101+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-26 0:41 Mercurial 0.3 vs git benchmarks Matt Mackall
2005-04-26 1:49 ` Daniel Phillips
2005-04-26 2:08 ` Linus Torvalds
2005-04-26 2:30 ` Mike Taht
2005-04-26 3:04 ` Linus Torvalds
2005-04-26 4:00 ` Linus Torvalds [this message]
2005-04-26 11:13 ` Chris Mason
2005-04-26 15:09 ` Magnus Damm
2005-04-26 15:38 ` Chris Mason
2005-04-26 16:23 ` Magnus Damm
2005-04-26 18:18 ` Chris Mason
2005-04-26 20:56 ` Andrew Morton
2005-04-26 21:07 ` Linus Torvalds
2005-04-26 22:50 ` H. Peter Anvin
2005-04-26 22:56 ` Andrew Morton
2005-04-26 23:43 ` H. Peter Anvin
2005-04-27 15:01 ` Florian Weimer
2005-04-27 15:13 ` Thomas Glanzmann
2005-04-27 18:54 ` H. Peter Anvin
2005-04-27 19:01 ` Thomas Glanzmann
2005-04-27 19:57 ` Theodore Ts'o
2005-04-27 20:06 ` Thomas Glanzmann
2005-04-27 20:35 ` H. Peter Anvin
2005-04-27 20:39 ` Thomas Glanzmann
2005-04-27 20:47 ` Florian Weimer
2005-04-27 20:55 ` Florian Weimer
2005-04-27 21:04 ` H. Peter Anvin
2005-04-27 21:06 ` Florian Weimer
2005-04-27 21:32 ` Theodore Ts'o
2005-04-27 19:55 ` Theodore Ts'o
2005-04-27 6:34 ` Ingo Molnar
2005-04-27 21:10 ` Bill Davidsen
2005-04-27 21:39 ` Linus Torvalds
2005-04-26 16:42 ` Linus Torvalds
2005-04-26 17:39 ` Chris Mason
2005-04-26 19:52 ` Chris Mason
2005-04-26 18:15 ` H. Peter Anvin
2005-04-26 20:30 ` Bill Davidsen
2005-04-26 16:11 ` Bill Davidsen
2005-04-26 4:01 ` Matt Mackall
2005-04-26 4:20 ` Linus Torvalds
2005-04-26 4:09 ` Chris Wedgwood
2005-04-26 4:22 ` Andreas Gal
2005-04-26 4:22 ` Linus Torvalds
2005-04-29 6:01 ` Mercurial 0.4b vs git patchbomb benchmark Matt Mackall
2005-04-29 6:40 ` Sean
2005-04-29 7:40 ` Matt Mackall
2005-04-29 8:40 ` Sean
2005-04-29 14:34 ` Linus Torvalds
2005-04-29 15:18 ` Morten Welinder
2005-04-29 16:52 ` Matt Mackall
2005-05-02 16:10 ` Bill Davidsen
2005-05-02 19:02 ` Sean
2005-05-02 22:02 ` Linus Torvalds
2005-05-02 22:30 ` Matt Mackall
2005-05-02 22:49 ` Linus Torvalds
2005-05-03 0:00 ` Matt Mackall
2005-05-03 2:48 ` Linus Torvalds
2005-05-03 3:29 ` Matt Mackall
2005-05-03 4:18 ` Linus Torvalds
2005-05-03 4:24 ` Linus Torvalds
2005-05-03 4:27 ` Matt Mackall
2005-05-03 8:45 ` Chris Wedgwood
2005-04-29 15:44 ` Tom Lord
2005-04-29 15:58 ` Linus Torvalds
2005-04-29 17:34 ` Tom Lord
2005-04-29 17:56 ` Linus Torvalds
2005-04-29 18:08 ` Tom Lord
2005-04-29 18:33 ` Sean
2005-04-29 18:54 ` Tom Lord
2005-04-29 19:13 ` Sean
2005-05-02 16:15 ` Bill Davidsen
2005-04-29 16:37 ` Matt Mackall
2005-04-29 17:09 ` Linus Torvalds
2005-04-29 19:12 ` Matt Mackall
2005-04-29 19:50 ` Linus Torvalds
2005-04-29 20:23 ` Matt Mackall
2005-04-29 20:49 ` Linus Torvalds
2005-04-29 21:20 ` Matt Mackall
2005-04-29 16:46 ` Bill Davidsen
2005-04-29 20:19 ` Andrea Arcangeli
2005-04-29 22:30 ` Olivier Galibert
2005-04-29 22:47 ` Andrea Arcangeli
2005-04-29 20:30 ` Andrea Arcangeli
2005-04-29 20:39 ` Matt Mackall
2005-04-30 2:52 ` Andrea Arcangeli
2005-04-30 15:20 ` Matt Mackall
2005-04-30 16:37 ` Andrea Arcangeli
2005-05-02 15:49 ` Bill Davidsen
2005-05-02 16:14 ` Valdis.Kletnieks
2005-05-03 17:40 ` Bill Davidsen
2005-05-04 2:10 ` Mercurial 0.4b vs git patchbomb benchmark (/usr/bin/env again) David A. Wheeler
2005-05-02 16:17 ` Mercurial 0.4b vs git patchbomb benchmark Andrea Arcangeli
2005-05-02 16:31 ` Linus Torvalds
2005-05-02 17:18 ` Daniel Jacobowitz
2005-05-02 17:32 ` Linus Torvalds
2005-05-02 20:54 ` Sam Ravnborg
2005-05-02 17:20 ` Ryan Anderson
2005-05-02 17:31 ` Linus Torvalds
2005-05-02 21:17 ` Kyle Moffett
2005-05-03 17:43 ` Bill Davidsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.58.0504252032500.18901@ppc970.osdl.org \
--to=torvalds@osdl.org \
--cc=git@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mike.taht@timesys.com \
--cc=mpm@selenic.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).