Using const fn constructor instead of struct expression with large number of constants causes compilation to fail because of large memory allocation.

[CDirkx]

I have:

• A struct CodePoint with a const fn from(...) -> Self constructor
• A large number of CodePoint constants (42.000+) using the constructor

#[repr(transparent)]
pub struct CodePoint {
    raw: u32
}

impl CodePoint {
    pub const fn from(raw: u32) -> Self {
        // debug_assert!(raw <= 0x10FFFF);
        CodePoint { raw }
    }
}

// include!(...)
// 42508 constants, 3.28MB file
impl CodePoint {
    pub const SPACE : CodePoint = CodePoint::from(32u32);
    ...
}

Building this leads to:

• Compiler busy for 2min+
• Compiler error trying to allocate 1.2GB:
  memory allocation of 1207959552 bytes failed
  even though I have 12GB of unused RAM

Using struct expressions instead of a const fn constructor:

impl CodePoint {
    pub const SPACE : CodePoint = CodePoint { raw: 32u32 };
    ...
}

• Compiler finishes within 5s.

Tested on nightly and stable, with include!(...) and copy-pasting: no differences.

Source file to reproduce: reproduce.zip

[CDirkx]

I know 42.000+ constants is probably not the best idea, but with the struct expression case finishing within 5s I would expect the compiler to be able to handle them, as the const constructor does exactly the same thing.

[ecstatic-morse]

The hot code here is rustc_typeck::check::method::<impl rustc_typeck::check::FnCtxt>::associated_item (80% CPU), which does a linear scan to find an associated item with a particular name. Seems like each associated const needs to do method lookup to find the constructor, which then needs to scan over all other associated consts before it finds CodePoint::from.

[ecstatic-morse]

@rustbot claim

[ecstatic-morse]

@CDirkx compile time has improved a lot in the current nightly. const_constructor now takes ~30s with a local, non-LTO master build compared to ~15s for struct_literal. #69072 will improve this further: const_constructor takes about the same amount of time as struct_literal with that PR applied.

[CDirkx]

Yes I can confirm that on the current nightly memory usage by rustc is way lower (not claiming multiple GBs of RAM anymore), resulting in not running out of memory anymore and succesfull compilation at the speeds you mention.

I also tried with all named Unicode code points included (including names like CJK_UNIFIED_IDEOGRAPH_2D6CE, 135.000+ total; reproduce_all.zip), this also compiled just fine while taking around 1.5 mins, which will be improved by your PR.

Thanks for taking the time to make Rust work with this admittedly non-standard code.

[ecstatic-morse]

@CDirkx if the issue has been resolved to your satisfaction, feel free to close it. #68837 was the PR that made the big difference here. There's no rush however.

I have another fix in mind in addition to #69072 to make compile-time linear/linearithmic in the number of associated items, so your compile times should continue to improve regardless of the status of this issue. I'm also looking to add a variation of your MCVE to the rustc-perf benchmarks so we don't regress this in the future.

Thank you for posting this in the first place. It made finding these rough spots very easy!