Skip to content

Large array literal causes slow compilation #37155

Open
@Veedrac

Description

@Veedrac

I have a large array of the form

static mut ARRAY: [AtomicU64; LARGE_NUMBER] = [
    ATOMIC_U64_INIT, ATOMIC_U64_INIT, ...
];

where LARGE_NUMBER = 512 * 1024. ATOMIC_U64_INIT is not Copy, so it's not obvious how to express this differently. I don't even think I even legally can use a [u64; LARGE_NUMBER] and transmute on use because u64 has aliasing guarantees that AtomicU64 breaks.

This ends up adding more than 10s to my compile times. time-passes, filtering out passes that take <0.1s above their baseline, shows

time: 0.594; rss: 322MB parsing
time: 0.295; rss: 349MB expansion
time: 0.244; rss: 404MB name resolution
time: 0.126; rss: 549MB lowering ast -> hir
time: 0.104; rss: 358MB region resolution
time: 0.148; rss: 358MB static item recursion checking
time: 0.497; rss: 359MB compute_incremental_hashes_map
time: 1.643; rss: 437MB item-types checking
time: 0.562; rss: 436MB const checking
time: 0.115; rss: 436MB privacy checking
time: 0.568; rss: 492MB MIR dump
time: 0.136; rss: 475MB death checking
time: 0.164; rss: 475MB stability checking
time: 0.559; rss: 475MB lint checking
  time: 3.098; rss: 523MB   translation item collection
time: 5.724; rss: 447MB translation

There's a full version available elsewhere, but it's not really more interesting.

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-enhancementCategory: An issue proposing an enhancement or a PR with one.I-compiletimeIssue: Problems and improvements with respect to compile times.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions