Build system became slower when changing from 0.15.1 to 0.16.0

Help
1

I have one project where I use Zig only as build system, not as compiler.

In total, there are 259 build steps, which consist of 14 mostly independent build artifacts with around 20 (more or less) build steps for each.

When running time zig build with Zig 0.15.1, the result is

real    0m8,650s
user    0m26,964s
sys     0m1,270s

but with Zig 0.16.0, the result is

real    0m17,525s
user    0m25,647s
sys     0m1,332s

i.e., the CPU work seems to be about the same, but it took about twice as long.

I noticed (using htop) that with 0.15.1, during the build all 4 CPU cores are evenly and continuously used to almost 100%, while with 0.16.0 mostly only 2 or 3 cores seem to be busy at a time (and only to about 90%), and the load fluctuates a lot.

Was there a change in the build system that explains this, and how can I get the previous behaviour again?

(In build.zig I had to replace one instance of std.mem.trimRight by std.mem.trimEnd, and one instance of std.ArrayList([]const u8){} by std.ArrayList([]const u8).empty. I assume that’s not the reason.)

2

I believe this might be due to migration to std.Io in all compiler code. And that is not yet fully polished out.

1 Like
3

https://codeberg.org/ziglang/zig/issues/31853

1 Like
4

From the ticket, about the previous behaviour:

Whenever a file is done compiling, a new file starts compiling, ensuring a near 100% usage of the CPU cores

Tbf, 100% CPU usage isn’t great behaviour either. On some desktop operating systems a fully loaded CPU makes the machine completely unusable (I’ve seen this especially on Windows laptops where the trackpad may become completely stuck during high CPU load).

5

Well, we can’t blame zig for trying to compile the project as fast as possible. Using every resource available is the way to achieve this. The problem you mentioned should be handled by the OS, which is expected to give things like GUI higher priority.

4 Likes
6

That’s how it was on the Amiga, the application with the active window got the highest priority (and the mouse input was directly interrupt driven anyway) Unfortunately that wisdom of the ancients seems to have been forgotten in our current UI dark age.

Theoretically Windows also has such a priority boost (see point 1 and 2: Priority Boosts - Win32 apps | Microsoft Learn), but it clearly doesn’t work in practice.

2 Likes