build.sh: don't use -m option for parallel

My reasoning was off. The -m flag does avoid the clang-tidy startup
 cost (which isn't large), but it also increases tail latency because it
 allows a straggler command to run much longer. Suppose that many heavy
 .cpp files are bundled into one clang-tidy invocation.

Bench from Greg
with -m
./build.sh --dbg --clean --no-simd --clang-tidy  3886.45s user 12.04s system 1066% cpu 6:05.71 total
without
./build.sh --dbg --clean --no-simd --clang-tidy  4297.51s user 41.70s system 1497% cpu 4:49.86 total
This commit is contained in:
Nicolas Hillegeer 2016-08-21 14:29:49 +02:00 committed by Gregory Hainaut
parent 27ea9c22bb
commit b2984cd3d0
1 changed files with 1 additions and 1 deletions

View File

@ -224,7 +224,7 @@ if [ "$clangTidy" -eq 1 ] && command -v clang-tidy >/dev/null ; then
# Don't check headers, don't check google/llvm coding conventions # Don't check headers, don't check google/llvm coding conventions
if command -v parallel >/dev/null ; then if command -v parallel >/dev/null ; then
# Run clang-tidy in parallel with as many jobs as there are CPUs. # Run clang-tidy in parallel with as many jobs as there are CPUs.
parallel -m "clang-tidy -p $compile_json -checks='*,-llvm-*,-google-*' {}" parallel "clang-tidy -p $compile_json -checks='*,-llvm-*,-google-*' {}"
else else
# xargs(1) can also run jobs in parallel with -P, but will mix the # xargs(1) can also run jobs in parallel with -P, but will mix the
# output from the distinct processes together willy-nilly. # output from the distinct processes together willy-nilly.