You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
rustc_driver.dll size on x86_64-pc-windows-gnu toolchain #92539
I noticed that the size of rustc_driver.dll for the windows x86_64-pc-windows-gnu toolchain seems suprisingly large compared to the x86-64-pc-windows-msvc toolchain. It's also been growing quickly in recent releases.
See chart below comparing the size of rustc_driver.dll for these two targets for stable releases since 1.40:
Some size difference is obviously expected, however the huge jump around Rust 1.54 (slightly over doubling of the file size) looks suspect.
Bisecting on nightlies around that time, it looks like the jump happened in nightly 2021-06-05:
nightly
x86_64-pc-windows-gnu rustc_driver size (bytes)
2021-06-03
199015985
2021-06-04
199027556
2021-06-05
442938696
2021-06-06
442876820
I've recently been working in an environment where the file size matters. I don't know much about the compiler packaging process, however I'd be happy to help investigate and (if possible) undo this jump in file size, with the help of someone willing to guide me where to look.
So far, I started out by looking at PRs merged on 2021-06-04 (i.e. the day before the size bump).
The only PR that stands out to me as potentially affecting file size is #84449. I am wildly speculating; this could be a red herring. I'm going to investigate this a little further. Input from others more knowledgeable than myself is very welcome!
Second, nightly 2021-06-05 for the gnu toolchain. Note that the output is very similar, except for a new .rmeta section. I'm not an expert on dumpbin output; if I understand the size of that section E87F000 is a hex size in bytes, that converts to a decimal size of about 240 MB, which would almost exactly explain the size jump.
cc @alexcrichton - is it possible that the "tricks" referenced in #84449 to remove the .rmeta section is not working correctly for the windows gnu toolchain?
The only caveat we
have to take care of is to ensure that the linker never actually
includes the contents of the object file into the final output. We apply
similar tricks as the .llvmbc bytecode sections to do this.
This would probably be fixed by #92107. There was a typo that prevented actually setting the necessary flag.
Edit: Actually, not sure on that. I think that would affect the size for the msvc target, not the gnu target, so the opposite of what is described here.
Oh dear I apologize for the bug here! It was definitely an oversight on my part to let that typo through.
IIRC I tested at least on MSVC that the flag was respected, but given the graph in this issue and the fact that the typo flew under the radar it seems the MSVC link.exe linker doesn't need this flag to be set to ensure that .rmeta doesn't make it into binaries. I don't remember whether I tested *-windows-gnu but I probably didn't. I agree with @nikic in that I'm not sure whether #92107 will fix this but it would be good to double-check after that lands to see what's going on. Otherwise there may be some other MinGW-linker-specific thing that can be done here.
changed the title [-]`rustc_driver.dll` size on `x86_64-pc-windows-gnu` target[/-][+]`rustc_driver.dll` size on `x86_64-pc-windows-gnu` toolchain[/+]on Jan 4, 2022
Activity
davidhewitt commentedon Jan 3, 2022
It looks like #84449 might well be relevant. Here's some outputs from
dumpbin:First, nightly 2021-06-04 for the
gnutoolchain:Second, nightly 2021-06-05 for the
gnutoolchain. Note that the output is very similar, except for a new.rmetasection. I'm not an expert ondumpbinoutput; if I understand the size of that sectionE87F000is a hex size in bytes, that converts to a decimal size of about 240 MB, which would almost exactly explain the size jump.cc @alexcrichton - is it possible that the "tricks" referenced in #84449 to remove the
.rmetasection is not working correctly for the windows gnu toolchain?nikic commentedon Jan 3, 2022
This would probably be fixed by #92107. There was a typo that prevented actually setting the necessary flag.
Edit: Actually, not sure on that. I think that would affect the size for the msvc target, not the gnu target, so the opposite of what is described here.
alexcrichton commentedon Jan 4, 2022
Oh dear I apologize for the bug here! It was definitely an oversight on my part to let that typo through.
IIRC I tested at least on MSVC that the flag was respected, but given the graph in this issue and the fact that the typo flew under the radar it seems the MSVC
link.exelinker doesn't need this flag to be set to ensure that.rmetadoesn't make it into binaries. I don't remember whether I tested*-windows-gnubut I probably didn't. I agree with @nikic in that I'm not sure whether #92107 will fix this but it would be good to double-check after that lands to see what's going on. Otherwise there may be some other MinGW-linker-specific thing that can be done here.davidhewitt commentedon Jan 4, 2022
Thanks both - I see #92107 is about to be merged in a rollup, so I'll check the next nightly produced after that lands and report back here.
[-]`rustc_driver.dll` size on `x86_64-pc-windows-gnu` target[/-][+]`rustc_driver.dll` size on `x86_64-pc-windows-gnu` toolchain[/+]davidhewitt commentedon Jan 5, 2022
Following up on this - it looks like #92107 has fixed this.
Output of
dumpbinwith today's nightly no longer shows the.rmetasection:rustc_driver.dllsize is now back at ~230MB, which seems about right when comparing against nightlies back in May 2021.Thanks @nikic for pushing a bugfix before I even reported this 😂
alexcrichton commentedon Jan 5, 2022
Nice! Apologies again on the oversight and thanks @nikic for fixing it!