git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

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