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

Destroying the LLVM Module is slow #3552

Closed
pcwalton opened this issue Sep 22, 2012 · 13 comments
Closed

Destroying the LLVM Module is slow #3552

pcwalton opened this issue Sep 22, 2012 · 13 comments
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. I-compiletime Issue: Problems and improvements with respect to compile times.

Comments

@pcwalton
Copy link
Contributor

About 3.1% of rustc compilation time (2.6 s) is spent destroying the LLVM module. For comparison, that's longer than all of resolve.

The solution is to leak the module and let the OS clean up all the memory.

@catamorphism
Copy link
Contributor

Nominating for milestone 5, production-ready.

@graydon
Copy link
Contributor

graydon commented May 16, 2013

just a bug, removing milestone/nomination.

@emberian
Copy link
Member

emberian commented Aug 5, 2013

Fixed pending #7659

brson added a commit to brson/rust that referenced this issue Aug 23, 2013
@brson
Copy link
Contributor

brson commented Aug 24, 2013

I've not yet convinced myself of the value of this. For large crates it does seem to provide some amount of savings, not for small crates though, so impact on cycle time will probably be minimal. Still want to do some testing. Also want to investigate just calling libc::exit to see if avoiding the final GC accomplishes anything.

@erickt
Copy link
Contributor

erickt commented Aug 25, 2013

Would leaking the LLVM module cause problems when librustc is used in an IDE or some other long running process?

@brson
Copy link
Contributor

brson commented Aug 25, 2013

@erickt Yes. If we do this it will be optional.

@sanxiyn
Copy link
Member

sanxiyn commented Jan 23, 2014

What happened to this?

@brson
Copy link
Contributor

brson commented Jan 24, 2014

@sanxiyn I don't recall, but I don't think there were any major issues with the patch I had, besides figuring out how to make valgrind happy.

@steveklabnik
Copy link
Member

Triage: nothing has moved on this.

@brson brson added E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. labels Jun 10, 2016
@brson
Copy link
Contributor

brson commented Jun 10, 2016

Nobody has looked at this in a long time. We can quickly test whether this is still a win: just remove all calls to llvm::LLVMDisposeModule(llmod); and compare the times of a clean rustc build before and after. If it improves compile time then we can make it an option with a flag in e.g. Session and turn it on for rustc.

If it doesn't improve compile time then we can finally close this issue.

@brson
Copy link
Contributor

brson commented Jun 10, 2016

On the other hand, this bug is based on four-year old information. Maybe we should just let it go.

@sanxiyn
Copy link
Member

sanxiyn commented Jun 10, 2016

Updated numbers on librustc: "name resolution" takes 0.3 seconds, "LLVM passes" takes 14.4 seconds, "LLVM passes" without dispose takes 14.1 seconds. So it is still true LLVM dispose takes as long as resolve.

On the other hand, total time is 50 seconds, so both LLVM dispose and resolve takes less than 1% of total time. I think we can close this.

Note: llvm::LLVMContextDispose(llcx) also needs to be removed, because context destructor calls module destructor. When I didn't remove it, memory usage in -Z time-passes stayed same. When I did, memory usage post-LLVM increased by 400 MB.

@brson brson closed this as completed Jun 27, 2016
@brson
Copy link
Contributor

brson commented Jun 27, 2016

Thanks for the measurements @sanxiyn !

RalfJung pushed a commit to RalfJung/rust that referenced this issue May 4, 2024
RalfJung pushed a commit to RalfJung/rust that referenced this issue May 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. I-compiletime Issue: Problems and improvements with respect to compile times.
Projects
None yet
Development

No branches or pull requests

9 participants