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

Incremental compilation - internalize symbols using up more than 1GB (double the RAM usage before) #41466

Closed
neon64 opened this issue Apr 22, 2017 · 8 comments
Labels
A-incr-comp Area: Incremental compilation C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@neon64
Copy link

neon64 commented Apr 22, 2017

It's my first time testing out incremental compilation and I encountered some issues building alacritty after making a negligible change... After speaking with @eddyb on IRC he suggested I open an issue here...

here is -Z time-passes with incremental compilation enabled:
https://gist.github.com/neon64/bb8ca569575b5e07b98da8805fd7c223
and without:
https://gist.github.com/neon64/50d005c24bb9da767615f5a5ba2cfc97

cc @nikomatsakis

@sfackler sfackler added A-incr-comp Area: Incremental compilation T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Apr 22, 2017
@michaelwoerister
Copy link
Member

cc me

@michaelwoerister
Copy link
Member

I suspect this is due to the higher number of codegen units/object files that incremental compilation produces. "internalize symbols" is the first thing where we measure memory consumption after all LLVM modules have been created. In non-incremental mode that's just one LLVM module, in incremental mode it's somewhere around 30 for this crate.

If you recompile with only a small change, memory consumption should be a lot lower (given that the change does not affect too many of the object files).

The issue of keeping all LLVM modules in memory at the same time is already recorded as #39280.

@eddyb
Copy link
Member

eddyb commented Apr 24, 2017

The way passes nest always throws me off! This makes a lot more sense.

@neon64
Copy link
Author

neon64 commented Apr 25, 2017

Thanks for the explanation. Should I close this issue in favour of #39280 then?

@neon64
Copy link
Author

neon64 commented Apr 25, 2017

Although I tried what you said an just made a small change (added a println!() statement in one file), and yet the memory usage was basically the same and it appeared as if all the LLVM modules were still being built.

@michaelwoerister
Copy link
Member

Although I tried what you said an just made a small change (added a println!() statement in one file), and yet the memory usage was basically the same and it appeared as if all the LLVM modules were still being built.

Can you tell me where exactly you made the change and which version of the crate that was?

@neon64
Copy link
Author

neon64 commented Apr 25, 2017

Okay I am using the latest version (a99a69c) and the change I made was inside src/input.rs, line after 323 (inside the on_mouse_wheel function) I added the following:

println!("Delta: {:?} Phase: {:?}", delta, phase);

@Mark-Simulacrum Mark-Simulacrum added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Jul 27, 2017
@alexcrichton
Copy link
Member

Since #39280 is now closed I'm going to close this as well

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-incr-comp Area: Incremental compilation C-enhancement Category: An issue proposing an enhancement or a PR with one. 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