From: Linus Torvalds <torvalds@linux-foundation.org>
To: Benjamin Kramer <benny.kra@googlemail.com>
Cc: Fredrik Kuivinen <frekui@gmail.com>,
Git Mailing List <git@vger.kernel.org>,
Junio C Hamano <gitster@pobox.com>,
Johannes Sixt <j.sixt@viscovery.net>
Subject: Re: [PATCH v4] Threaded grep
Date: Tue, 26 Jan 2010 08:56:50 -0800 (PST) [thread overview]
Message-ID: <alpine.LFD.2.00.1001260846330.3574@localhost.localdomain> (raw)
In-Reply-To: <alpine.LFD.2.00.1001260836520.3574@localhost.localdomain>
On Tue, 26 Jan 2010, Linus Torvalds wrote:
>
> Goodie. It's noticeable for me. This is what I reported earlier:
>
> > > $ /usr/bin/time git grep void
> >
> > Before:
> >
> > real 0m1.144s
> >
> > After:
> > real 0m0.290s
>
> and with your patch I get
>
> real 0m0.239s
Btw, I have to also say that this whole performance reduction _feels_
good. It's very noticeable in normal use. "git grep" was always fast (it's
been getting a bit slower as the kernel has grown, though), but it used to
be still a noticeable pause.
Now it just -feels- very immediate. That quarter second is short enough
that I can see the pause, but I don't feel it. It's like the results just
"are there" rather than get searched for.
But perhaps even more importantly, it's also noticeable for me in the
cold-cache case. IOW, after I do
echo 3 > /proc/sys/vm/drop_caches
the threaded grep is able to do much better at reading the disk:
Before threading:
[torvalds@nehalem linux]$ time git grep void > /dev/null
real 0m11.745s
user 0m2.380s
sys 0m1.200s
After:
[torvalds@nehalem linux]$ time ~/git/git grep void > /dev/null
real 0m3.710s
user 0m2.564s
sys 0m2.076s
although it is worth noting that that machine has an Intel SSD, which is
why it gets sped up so much by parallel IO (there's no seek penalty, and
it is able to read multiple channels in parallel, so this gives much
better IO patterns for it - with rotational media the numbers might be
very different).
IOW, the whole threaded grep thing is a 4x performance improvement in
hot-cache, and a 3x improvement in cold-cache.
Major good mojo.
Linus
next prev parent reply other threads:[~2010-01-26 16:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-25 22:51 [PATCH v4] Threaded grep Fredrik Kuivinen
2010-01-25 23:59 ` Linus Torvalds
2010-01-26 12:10 ` Fredrik Kuivinen
2010-01-26 15:28 ` Linus Torvalds
2010-01-26 16:30 ` Benjamin Kramer
2010-01-26 16:44 ` Linus Torvalds
2010-01-26 16:56 ` Linus Torvalds [this message]
2010-01-26 17:19 ` Mike Hommey
2010-01-26 17:48 ` [PATCH] grep: use REG_STARTEND (if available) to speed up regexec Benjamin Kramer
2010-01-26 1:20 ` [PATCH v4] Threaded grep Junio C Hamano
2010-01-26 11:43 ` Fredrik Kuivinen
2010-01-26 17:21 ` Junio C Hamano
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=alpine.LFD.2.00.1001260846330.3574@localhost.localdomain \
--to=torvalds@linux-foundation.org \
--cc=benny.kra@googlemail.com \
--cc=frekui@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=j.sixt@viscovery.net \
/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).