August 13, 2025・6 minute read
Many software projects take a long time to compile. Sometimes that’s just due to the sheer amount of code, like in the LLVM project. But often a build is slower than it should be for dumb, fixable reasons.
I’ve had the suspicion that most builds are doing dumb stuff, but I had no way to see it. So I’ve been working on a cross-platform tool to help speed up builds (you can try it, see below). It works with any build system or programming language (Not just C/C++). Its timeline looks like this:
It’s more than just a generic system profiler: it looks for build-specific problems. A few examples: using make without the -j flag, disproportionate time being spent on certain files or compiler phases (as reported by tools like clang’s -ftime-trace ), and commands that could’ve been run in parallel but weren’t. It’s especially helpful for optimizing CI builds, which are often clean rebuilds without caching.
I named it What the Fork after the fork() system call that spawns new processes. You use it by writing wtf before a build command:
$ # A few possible examples: $ wtf make $ wtf cargo build $ wtf gradle build $ wtf npm run build $ wtf zig build $ wtf -x # starts a build of the front most Xcode window
Here it is recording the build of a macOS app:
Your browser does not support the video tag.
How it works
A build is just a bunch of commands that produce your finished program. At its simplest, it could be a shell script like this:
... continue reading