Re: [PATCH 01/12] grep: add ability to disable threading with --threads=0 or grep.threads=0

From: Jeff King <peff@peff.net>
Date: Apr 11, 2017, 20:34 UTC
Message-ID: <20170411203434.iiupo2oovzviqju5@sigill.intra.peff.net>
In-Reply-To: <CACBZZX7vEQ5jUzX3GsD6JXe50TnRUtGmSVi7zBxwOmAQGABQ4Q@mail.gmail.com>

On Tue, Apr 11, 2017 at 10:20:59PM +0200, Ævar Arnfjörð Bjarmason wrote:

> I'm struggling to find a use-case where threading makes sense at all.
> The example in the initial introduction in 5b594f457a is always slower
> with >0 for me, and since then in 0579f91dd7 it got disabled entirely
> for non-worktree cases.

It's a big win for me in worktree greps of linux.git:

  $ best-of-five git grep --threads=1 '[q]werty'
  Attempt 1: 0.713
  Attempt 2: 0.708
  Attempt 3: 0.689
  Attempt 4: 0.695
  Attempt 5: 0.7

  real	0m0.689s
  user	0m0.560s
  sys	0m0.248s

  $ best-of-five git grep --threads=8 '[q]werty'
  Attempt 1: 0.238
  Attempt 2: 0.225
  Attempt 3: 0.222
  Attempt 4: 0.221
  Attempt 5: 0.225

  real	0m0.221s
  user	0m0.936s
  sys	0m0.356s

In non-worktree cases most of the time goes to accessing objects, which happens under a lock. So you don't get any real parallelism, just overhead.

> But assuming it works for someone out there, then 0 threads is clearly
> not the same as 1. On linux.git with pcre2 grepping for [q]werty for
> example[1]

Right, my suggestion was to teach "grep" to treat --threads=1 as "do not spawn any other threads". I.e., to make it like the "0" case you were proposing, and then leave "0" as "auto-detect". There would be no way to spawn a _single_ thread and feed it. But why would you want to do that? It's always going to be strictly worse than not threading at all.

-Peff