# What allows comptime to not increase compile times significantly in many cases? **URL:** \ **Category:** Explain\ **Created:** [November 16, 2025, 12:12am UTC](https://ziggit.dev/t/what-allows-comptime-to-not-increase-compile-times-significantly-in-many-cases/13062 "2025-11-16T00:12:52Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![leauxgan](https://ziggit.dev/user_avatar/ziggit.dev/leauxgan/32/4478_2.png) [@leauxgan](https://ziggit.dev/u/leauxgan)\ **Post date:** [November 16, 2025, 12:12am UTC](https://ziggit.dev/t/what-allows-comptime-to-not-increase-compile-times-significantly-in-many-cases/13062/1 "2025-11-16T00:12:52Z")
I’m looking for more resources into how comptime works and how compile times can still be so low even when it can provide features similar to macros. I’ve only heard a bit about how ZIR analysis works based on posts from mlugg, but I’m not sure why comptime doesnt seem to bloat compile times like heavy use of macros often does. ---
**Author:** ![vulpesx](https://ziggit.dev/user_avatar/ziggit.dev/vulpesx/32/3989_2.png) [@vulpesx](https://ziggit.dev/u/vulpesx)\ **Post date:** [November 16, 2025, 12:18am UTC](https://ziggit.dev/t/what-allows-comptime-to-not-increase-compile-times-significantly-in-many-cases/13062/2 "2025-11-16T00:18:41Z")
It does increase compile time significantly, comptime is slower than python atm. It’s just that most use cases are very simple so you don’t notice it. ---
**Author:** ![npc1054657282](https://ziggit.dev/user_avatar/ziggit.dev/npc1054657282/32/5790_2.png) [@npc1054657282](https://ziggit.dev/u/npc1054657282)\ **Post date:** [November 16, 2025, 12:35am UTC](https://ziggit.dev/t/what-allows-comptime-to-not-increase-compile-times-significantly-in-many-cases/13062/3 "2025-11-16T00:35:16Z")
I feel that a simple way to evaluate it is: if your comptime usage doesn’t require using `setEvalBranchQuota`, then the increase in compilation time for this use case is not very noticeable. ---
**Author:** ![squeek502](https://ziggit.dev/user_avatar/ziggit.dev/squeek502/32/409_2.png) [@squeek502](https://ziggit.dev/u/squeek502)\ **Post date:** [November 16, 2025, 7:34am UTC](https://ziggit.dev/t/what-allows-comptime-to-not-increase-compile-times-significantly-in-many-cases/13062/4 "2025-11-16T07:34:09Z")
Very relevant comment re:speed: > > > 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? And a relevant thread re:implementation: > [@Implementation of Comptime](https://ziggit.dev/t/implementation-of-comptime/5041): > > Continuing the discussion from [Is there something like Rust's cargo expand for Zig's comptime](https://ziggit.dev/t/is-there-something-like-rusts-cargo-expand-for-zigs-comptime/5035/5): I’ve been curious about the details of this for a long time. Are there any resources which go into details about the specifics of comptime’s implementation? I’ve read some of the compiler trying to glean more about this, but it seems to be sort of… spread out, if that makes sense. I know there are some issues tracking things like speeding it up and making it possible to allocate during comptime, an… ---
**Author:** ![matklad](https://ziggit.dev/user_avatar/ziggit.dev/matklad/32/2462_2.png) [@matklad](https://ziggit.dev/u/matklad)\ **Post date:** [November 17, 2025, 11:14am UTC](https://ziggit.dev/t/what-allows-comptime-to-not-increase-compile-times-significantly-in-many-cases/13062/5 "2025-11-17T11:14:30Z")
My mental model is that it isn’t that comptime is slow, but that you can use it to generate lots of code, and compiling that code is what’s slow (and makes your binary huge). That’s the same deal as with Rust proc macros — proc macros aren’t the fastest way to execute logic, but, in the grand scheme of things, this doesn’t matter, because the actual problem is not macros per se, but people using macros to generate loads of work for compiler with relatively innocuous-looking source code. ---
**Author:** ![Sze](https://ziggit.dev/user_avatar/ziggit.dev/sze/32/496_2.png) [@Sze](https://ziggit.dev/u/Sze)\ **Post date:** [November 17, 2025, 12:43pm UTC](https://ziggit.dev/t/what-allows-comptime-to-not-increase-compile-times-significantly-in-many-cases/13062/6 "2025-11-17T12:43:15Z")
I think a slight difference between comptime and macros is that with macros this can continue in a recursively more meta level, for example when you start using macros to write macros which generate macros that write macros …, with Zig you still can write comptime code which generates code which uses other comptime code, but because the syntax of the language remains fixed, doing this eventually leads to visibly and syntactically more friction that can be observed, while macros allow hiding that increase in complexity behind syntax extension that looks like it is part of the language. So with macros you can recursively add more and more meta-programming levels to a language, with Zig it is more clearly visible when somebody adds additional levels of meta programming, because that means that they will embed dsl code in comptime strings or other comptime values, that are clearly distinct from normal Zig code. When it is easy to hide many levels of meta programming it also becomes more likely that such explosions in code size will happen. When people are forced to see the complexity they are more likely to abandon trying to implement things requiring too much meta programming via embedded meta programming and then write a code generator instead, where they are again forced to explicitly deal with complexity, instead of having it almost invisibly auto-generated by macro system. While I have appreciation for macro systems and some of the things they allow, I think they don’t make it particular easy to deal with complexity and make it relatively easy to accumulate more complexity than you would expect. I also think that macros are just one way of doing meta programming and that some of the other ways may have their own benefits (so I think it is good when languages explore alternatives to macros).