Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Large array literal causes slow compilation #37155

Open
Veedrac opened this issue Oct 13, 2016 · 5 comments
Open

Large array literal causes slow compilation #37155

Veedrac opened this issue Oct 13, 2016 · 5 comments
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one. I-compiletime Issue: Problems and improvements with respect to compile times. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@Veedrac
Copy link
Contributor

Veedrac commented Oct 13, 2016

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.

@arielb1
Copy link
Contributor

arielb1 commented Oct 14, 2016

You can absolutely transmute if you use an UnsafeCell, which discard aliasing assumptions.

#![feature(const_fn, integer_atomics)]

use std::cell::UnsafeCell;
use std::sync::atomic::AtomicU64;

pub struct SyncCell<T>(UnsafeCell<T>);
unsafe impl<T: Sync> Sync for SyncCell<T> {}

static XYZ: SyncCell<[u64; 1024*512]> =
    SyncCell(UnsafeCell::new([0; 1024*512]));

pub fn get_xyz() -> &'static [AtomicU64; 1024*512] {
    unsafe {&*(XYZ.0.get() as *mut _)}
}

fn main() {}

@Veedrac
Copy link
Contributor Author

Veedrac commented Oct 14, 2016

That's much better, thanks! I'll leave the issue open for now, since this indicates a bottleneck in translation, but it's no longer an immediate problem.

@Mark-Simulacrum
Copy link
Member

https://gist.github.com/Mark-Simulacrum/a83196ed84920c37804654ec39a7ebe9 is the full time-passes log from today, with the relevant passes:

time: 1.191; rss: 206MB parsing
time: 1.578; rss: 391MB stability checking
time: 14.975; rss: 494MB        item-types checking                        ***
time: 2.139; rss: 532MB const checking
time: 3.860; rss: 556MB borrow checking
time: 1.065; rss: 556MB lint checking
  time: 2.718; rss: 556MB       translation item collection
time: 11.775; rss: 560MB        translation                                ***

@Mark-Simulacrum Mark-Simulacrum added the I-compiletime Issue: Problems and improvements with respect to compile times. label Jun 22, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Jul 26, 2017
@RalfJung
Copy link
Member

RalfJung commented Aug 6, 2018

See #52868 (comment) for a quick test case demonstrating that compile time scales quadratically with array size.

@jonas-schievink jonas-schievink added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jan 31, 2020
@Enselic
Copy link
Member

Enselic commented Nov 20, 2023

Triage: Still reproduces with nightly-2023-11-17 using the following reproducer taken from #58523.

pub fn main() {
    let mut _buf = vec![0u8; 1 << 32];
    (&[0u8; (1 << 32) - 8]);
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one. I-compiletime Issue: Problems and improvements with respect to compile times. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

6 participants