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

squeek502 · November 16, 2025, 7:34am

Very relevant comment re:speed:

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

opened 05:36AM - 03 Jan 20 UTC

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?

And a relevant thread re:implementation: