| Message ID | 20240710083513.GB2060601@coredump.intra.peff.net (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | a7c1c102562c141b752f06f94c99438fa80319e8 |
| Headers | show |
| Series | here-doc test bodies (now with 100% more chainlinting) | expand |
diff --git a/t/chainlint.pl b/t/chainlint.pl index 1bbd985b78..1864d048ae 100755 --- a/t/chainlint.pl +++ b/t/chainlint.pl @@ -807,7 +807,8 @@ sub exit_code { exit; } -unless ($Config{useithreads} && eval { +unless ($jobs > 1 && + $Config{useithreads} && eval { require threads; threads->import(); require Thread::Queue; Thread::Queue->import(); 1;
If the system supports threads, chainlint.pl will always spawn worker threads to do the real work. But when --jobs=1, this is pointless, since we could just do the work in the main thread. And spawning even a single thread has a high overhead. For example, on my Linux system, running: for i in chainlint/*.test; do perl chainlint.pl --jobs=1 $i done >/dev/null takes ~1.7s without this patch, and ~1.1s after. We don't usually spawn a bunch of individual chainlint.pl processes (instead we feed several scripts at once, and the parallelism outweighs the setup cost). But it's something we've considered doing, and since we already have fallback code for systems without thread support, it's pretty easy to make this work. Signed-off-by: Jeff King <peff@peff.net> --- t/chainlint.pl | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)