Comptime evaluation takes forever

TT365 · May 19, 2026, 10:00am

I am writing a program in Zig that I want to use to figure out something for fun but I am stuck with a part where I cannot find a nice implementation.

I have a fixed list of 3408 Unicode coded words (all 5 letter words in the Finnish language). I want to translate this into a list of [5]u16’s that I will call word_list. I will use subsets of the word_list with bit_sets. So the word_list is a constant.

The problematic piece of code is below; Word is [5]u16.

const WordList = struct {
     const number_of_words: usize = 3408;
     const all_words: [number_of_words][ ] const u8 = @import("all_words.zig").words; 
 
     word_list: [number_of_words]Word,
 
     fn create() WordList {
         var words: [number_of_words]Word = undefined;
         @setEvalBranchQuota(200000);
         for (0..number_of_words) |i| {
             words[i] = Word.fromUtf8(all_words[i]) catch .dummy();
         }
         return .{ .word_list = words };
     }
     fn get(self: WordList, index: usize) Word {
         return self.word_list[index];
     }
 };
 
const word_list = WordList.create();

The problem is that this code takes over 80 seconds to compile. Am I missing something or is it just a fact of life that comptime code is much much slower than runtime?

vulpesx · May 19, 2026, 10:12am

comptime is currently slower than python, there is a goal to get it roughly equivalent to cpython.

For heavy pre computations you’re better off creating a separate program to compute it, ran by the build system, and embedding the result into the final binary.

andrewrk · May 20, 2026, 8:03pm

tracking issue:

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?