mirror of https://github.com/PCSX2/pcsx2.git
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:
parent
27ea9c22bb
commit
b2984cd3d0
2
build.sh
2
build.sh
|
@ -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
|
||||
if command -v parallel >/dev/null ; then
|
||||
# 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
|
||||
# xargs(1) can also run jobs in parallel with -P, but will mix the
|
||||
# output from the distinct processes together willy-nilly.
|
||||
|
|
Loading…
Reference in New Issue