Surely you don't mean the code in the OP takes you 15 minutes to compile in release mode; it's a 100-line file with no dependencies, and no macros or generics to hide codegen behind, and can't take more than an instant to compile. To get to a 15-minute-long release build you'd either need a very large amount of code or you may be attempting extensive type-level programming that rustc was not designed to support. You may also want to try swapping out your linker; ditching the system linker for gold or lld can have dramatic results if you're bottlenecked on the link stage.

Not the code linked from the article; the goal of that code was to generate the scores of the guesses at the root of the search tree, so that I could hardcode them in.

The commit which hardcodes them in is the one that starts having slow compilation: https://github.com/espadrine/optimal-wordle/blob/2e71cb4ca46...

It is possible that there is a recommended way to do it differently which I missed. I tried lazy_static!, but ended up having to fight the type system, and the related GitHub issues didn’t bring me hope that I could overcome it easily.

Interesting, you appear to be hitting some kind of pathological case with the `vec!` macro. Apparently it doesn't like being used with a 15,000-line literal. :P Fortunately you're right, there's a different way to do this, which AFAICT doesn't suffer from the same pathology. I replaced this:

    pub struct Choice {
        pub word: String,
        pub avg_remaining: f64,
    }

    pub fn root_choices() -> Vec<Choice> {
        vec![
            Choice { word: "roate".to_string(), avg_remaining: 60.42462203023758 },

with this:

    use std::borrow::Cow;

    #[derive(Clone)]
    pub struct Choice<'a> {
        pub word: Cow<'a, str>,
        pub avg_remaining: f64,
    }

    pub const ROOT_CHOICES: &[Choice] = &[
        Choice { word: Cow::Borrowed("roate"), avg_remaining: 60.42462203023758 },

and it brought the time of `cargo clean && cargo build --release` down from 345 seconds to 13 seconds. I consider this a compiler bug, I'll file it if I can't find an existing issue.

Oh, thanks! That is exactly what I wanted; a global constant makes more sense for this use-case.