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