summaryrefslogtreecommitdiff
path: root/builtin/rm.c
diff options
context:
space:
mode:
authorLibravatar Thomas Rast <trast@student.ethz.ch>2011-12-12 22:16:08 +0100
committerLibravatar Junio C Hamano <gitster@pobox.com>2011-12-16 15:47:25 -0800
commit53b8d931b649a0d82e16358a6bf1dd980dc24a6b (patch)
tree72599a8be5639a34231de0de586a670be62ffc3e /builtin/rm.c
parentgrep: enable threading with -p and -W using lazy attribute lookup (diff)
downloadtgif-53b8d931b649a0d82e16358a6bf1dd980dc24a6b.tar.xz
grep: disable threading in non-worktree case
Measurements by various people have shown that grepping in parallel is not beneficial when the object store is involved. For example, with a simple regex: Threads | --cached case | worktree case ---------------------------------------------------------------- 8 (default) | 2.88u 0.21s 0:02.94real | 0.19u 0.32s 0:00.16real 4 | 2.89u 0.29s 0:02.99real | 0.16u 0.34s 0:00.17real 2 | 2.83u 0.36s 0:02.87real | 0.18u 0.32s 0:00.26real NO_PTHREADS | 2.16u 0.08s 0:02.25real | 0.12u 0.17s 0:00.31real This happens because all the threads contend on read_sha1_mutex almost all of the time. A more complex regex allows the threads to do more work in parallel, but as Jeff King found out, the "super boost" (much higher clock when only one core is active) feature of recent CPUs still causes the unthreaded case to win by a large margin. So until the pack machinery allows unthreaded access, we disable grep's threading in all but the worktree case. Helped-by: René Scharfe <rene.scharfe@lsrfire.ath.cx> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'builtin/rm.c')
0 files changed, 0 insertions, 0 deletions