Skip to content

Vec deallocation is extremely slow on Windows #18081

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

Closed
nstoddard opened this issue Oct 16, 2014 · 2 comments
Closed

Vec deallocation is extremely slow on Windows #18081

nstoddard opened this issue Oct 16, 2014 · 2 comments

Comments

@nstoddard
Copy link

On Windows, deallocation of Vecs is extremely slow, orders of magnitude slower than on Linux. I have some sample code below; after it prints "Initialized x...", it takes several seconds to deallocate x. If I use an array instead, it's nearly instantaneous on both platforms.

I'm using Windows 7, 64-bit, with 32-bit Rust.

Edit: If I pass the -O flag to rustc, it performs as expected. Still, I think this optimization is important enough that it might be worth enabling by default.

fn main() {
  let x = box Vec::from_elem(50000000, 5.0f32);
  // let x = box [5.0f32, ..50000000];

  println!("Initialized x with length: {}", x.len());
}
@thestinger
Copy link
Contributor

Still, I think this optimization is important enough that it might be worth enabling by default.

Optimizations are never going to be enabled by default at --opt-level=0. If you want optimizations, you enable them.

@thestinger
Copy link
Contributor

Closing as a duplicate of #17633. The only reason this is slower on Windows is due to the much slower virtual memory handling. It's not Rust's fault that Windows handles a bunch of page faults slower.

lnicola pushed a commit to lnicola/rust that referenced this issue Sep 25, 2024
…r=Veykril

Use more correct handling of lint attributes

The previous analysis was top-down, and worked on a single file (expanding macros). The new analysis is bottom-up, starting from the diagnostics and climbing up the syntax and module tree.

While this is more efficient (and in fact, efficiency was the motivating reason to work on this), unfortunately the code was already fast enough. But luckily, it also fixes a correctness problem: outline parent modules' attributes were not respected for the previous analysis. Case lints specifically did their own analysis to accommodate that, but it was limited to only them. The new analysis works on all kinds of lints, present and future.

It was basically impossible to fix the old analysis without rewriting it because navigating the module hierarchy must come bottom-up, and if we already have a bottom-up analysis (including syntax analysis because modules can be nested in other syntax elements, including macros), it makes sense to use only this kind of analysis.

Few other bugs (not fundamental to the previous analysis) are also fixed, e.g. overwriting of lint levels (i.e. `#[allow(lint)] mod foo { #[warn(lint)] mod bar; }`.

After this PR is merged I intend to work on an editor command that does workspace-wide diagnostics analysis (that is, `rust-analyzer diagnostics` but from your editor and without having to spawn a new process, which will have to analyze the workspace from scratch). This can be useful to users who do not want to enable check on save because of its overhead, but want to see workspace wide diagnostics from r-a (or to maintainers of rust-analyzer).

Closes rust-lang#18086.
Closes rust-lang#18081.
Fixes rust-lang#18056.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants