Techniques for optimizing compile time?

ijdo · July 5, 2025, 9:52am

I extensively (ab)use comptime. Right now my debug-build compile time is reaching 41s on a very powerful Mac (forgive me that).

Are there any tools or techniques people use to profile/optimize compile times? e.g. I’d love to get a profile of the comptime interpreter so I can know which parts to optimize manually.

There is a side-answer to this which is use the native x86 backend with incremental compilation on linux. But that’s treating a symptom with a more significant change. I’m interested, more generally, in approaches to optimizing comptime use.

squeek502 · July 5, 2025, 10:04am

The glib answer would be: dive headfirst into Zig compiler development and resolve

github.com/ziglang/zig

improve comptime performance to roughly, generally the same as CPython execution speed of equivalent Python code

opened 05:36AM - 03 Jan 20 UTC

squeek502

enhancement optimization frontend

While investigating https://github.com/ziglang/zig/issues/3863, I ran into an un…expected problem: the performance of certain things (in my case, `std.hash.Wyhash` and `std.sort.sort`) is hugely degraded during comptime. Here's a test file that shows the problem using `std.sort`: ```zig const std = @import("std"); const num_values: usize = 10000; const expected_first_element: usize = num_values - 1; fn sortSomething() usize { var buf = init: { var arr: [num_values]usize = undefined; for (arr) |*v, i| { v.* = i; } break :init arr; }; std.sort.sort(usize, buf[0..], std.sort.desc(usize)); return buf[0]; } test "comptime" { @setEvalBranchQuota(100000); comptime std.testing.expectEqual(expected_first_element, sortSomething()); } test "runtime" { std.testing.expectEqual(expected_first_element, sortSomething()); } ``` The runtime test on its own (`--test-filter runtime`) runs very quickly (as expected) with `num_values = 10000`. For comptime, however, here's what I get with various different `num_values`: | `num_values` | time spent compiling | memory usage | status | | --- | --- | --- | --- | | 10 | 1s | ? | OK | | 100 | 1s | ? | OK | | 1000 | 3s | 500mb | OK | | 10000 | 75s | 3gb | evaluation exceeded 100000 backwards branches | (tested with zig `0.5.0+33d9dda55` on Windows) I would assume most of this is due to things like gathering stack traces for potential compile errors and things like that, but maybe there needs to be a way to disable that for certain comptime blocks? Or maybe its something else that's causing the performance issues here?

Other relevant issues more in line with your question:

ijdo · July 5, 2025, 10:20am

Thanks for the links. Yeah, diving in and working directly on it would be great. Not possible right now, but hopefully something we can do (and/or help fund in some way) in the near future.

IntegratedQuantum · July 5, 2025, 10:31am

There is no direct way to measure it yet. But there are indirect ways you could use.
Compile time correlates with binary size → the more code it has to emit the slower it is. (Of course this doesn’t take into account runtime interpreted code, but generally if a large portion of your compile time is spend in LLVM emit object, then code size is a good proxy for compile time)

On Linux you can display the size of all functions in a binary using nm.
Here is an example command that filters all functions and sorts them by size

nm --print-size --size-sort --reverse-sort ./zig-out/bin/your_executable_name | grep "[0-9a-f]* [0-9a-f]* [tT]" > out.txt

In the output you can then look for your comptime duplicated functions. E.g. I can find around 80 copies of reallocAdvanced near the top with 3kB binary size each. So if I wanted to optimize compile time, then this would be something to look into

matklad · July 5, 2025, 10:37am

Don’t do that? Comptime is like salt, it’s most tasteful in a pinch!

ijdo · July 5, 2025, 10:41am

I agree, but it’s so powerful… I fear I’ve made a cheeseburger; huge amounts of salt but it somehow works so well!

Unfortunately at this stage it’s not viable to wholesale change the codebase to remove a lot of comptime usage. It will be in the future, but until then we must make do