-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Comments
Nominating for milestone 5, production-ready. |
just a bug, removing milestone/nomination. |
Fixed pending #7659 |
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. |
Would leaking the LLVM module cause problems when librustc is used in an IDE or some other long running process? |
@erickt Yes. If we do this it will be optional. |
What happened to this? |
@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. |
Triage: nothing has moved on this. |
Nobody has looked at this in a long time. We can quickly test whether this is still a win: just remove all calls to If it doesn't improve compile time then we can finally close this issue. |
On the other hand, this bug is based on four-year old information. Maybe we should just let it go. |
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: |
Thanks for the measurements @sanxiyn ! |
even out CI runner times
even out CI runner times
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.
The text was updated successfully, but these errors were encountered: