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