# What allows comptime to not increase compile times significantly in many cases?

**URL:** <https://ziggit.dev/t/what-allows-comptime-to-not-increase-compile-times-significantly-in-many-cases/13062>\
**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:** 1\
**Showing post:** 4

<div class="post-metadata">

**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")

</div>

Very relevant comment re:speed:

> <https://github.com/ziglang/zig/issues/4055#issuecomment-1646701374>
>
> 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…

---

_[View the full topic](https://ziggit.dev/t/what-allows-comptime-to-not-increase-compile-times-significantly-in-many-cases/13062)._