From ea71e0d8b274f0d49cb53f650ddf1e0875e0f1f9 Mon Sep 17 00:00:00 2001 From: Simone Date: Sun, 17 May 2026 21:26:23 +0200 Subject: [PATCH] perf(linux): full make -j per parallel config (no //nconfigs split) Splitting make -j across configs (jobs // nconfigs) made each parallel config single-threaded on a 4-vCPU VM, so 3 concurrent serial builds were as slow as the old sequential path (~7min). Windows (MSBuild) runs the 3 configs in parallel each using all cores and finishes in ~2min on the same vCPU/RAM. Mirror that: give every parallel config the full make -j; the scheduler absorbs the mild oversubscription. Co-Authored-By: Claude Opus 4.7 --- tools/linux/build_plugin_linux.py | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/tools/linux/build_plugin_linux.py b/tools/linux/build_plugin_linux.py index a31aeb1..04e3370 100644 --- a/tools/linux/build_plugin_linux.py +++ b/tools/linux/build_plugin_linux.py @@ -350,9 +350,14 @@ def main() -> int: wanted = list(CONFIGS.keys()) if "all" in args.configs else args.configs if args.parallel and len(wanted) > 1: - # Split make jobs across configs so 3 concurrent makes don't - # oversubscribe the CPU (mirrors the Windows parallel build). - per_jobs = max(1, jobs // len(wanted)) + # Each config gets the FULL make -j (no //nconfigs split). The + # configs are independent; mild CPU oversubscription is handled + # by the scheduler and is still far faster than serial — this is + # exactly what the Windows (MSBuild) parallel build does, which + # finishes in ~2min on the same vCPU/RAM. Splitting -j across + # configs neutered intra-config parallelism (on a 4-vCPU VM it + # became make -j1) and gave no speedup. + per_jobs = jobs print( f"[linux] Building {len(wanted)} configs in parallel " f"(make -j{per_jobs} each)"