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
Binary sizes with debug info grew 35% after r143097 #11695
Comments
The 5% slowdown is happening on mac as well. I didn't look at .o file size on mac. |
Nick, this has been pinned on your debug info change, can you take a look? |
Yep, already investigating. The largest growth is 2MB in one .o file which is in turn caused by 100,000 new relocations (it previously had 20,000 relocs). |
There isn't much I can do here. The options I see are:
We could also make any of the above "revert" options controlled by flags. Hans and Nico, how bad is this impact of this size growth? I'd like to go with option 1, but then I'm not the one feeling the pain. :) |
I'll ask Greg about r143186 |
We don't need the relocations on the DW_FORM_strp entries on darwin. The linker doesn't link the DWARF, dsymutil does, and it doesn't use any relocations for the strings in the string table. I would be surprised if other linkers do as well since you would want to unique the strings anyway when putting them into the string table, so I am not sure how a relocation helps the linker? |
The linker does unique the strings in the string table, but it doesn't currently read through the debug info to find the references to those strings, instead relying on the table of relocations. |
Actually, Nico, can you give me a file that is showing a slowdown on the Mac? I don't recall anything abnormal happening that day and I'd hope to notice a 5% slowdown across the board... |
nlewycky: We already build without debug info on (almost) all our clang linux bots because the debug info is so huge. We had hoped that r143097 would improve things, but we can just keep debug info disabled on the bots. (It's not so great for developers who build with clang and use a distributed build system.) echristo: I only measured a full chrome build and an incremental build. In the incremental build case, ld runs most of the time. I don't have a single file at hand for this. |
It's not the end of the world. I just jumped when I was expecting a size decrease and saw an increase instead. |
Oh I see. Yes, I knew that this would increase the size of the .o files, but should also decrease the size of the linked binary. I hadn't measured how much the .o files would increase by, however... |
Nick raises a good question, did you guys see a decrease in size for the final linked binary? |
Ah, indeed we do. The final debug binary has gone from 3.5G in r143096 to 1.6G in r143097. |
Wow, great. This sounds like "behaves correctly" then. |
Agreed, let's close this bug. There are other reasons our .o files are so large, but we should attack those independently. |
Sounds reasonable. I can, btw, duplicate the slowdown on osx before and after the patch. Wall clock time regressed about 3% (not too bad), but system time regressed about 12% in a full rebuild of clang. |
Extended Description
The total size of .o files when building Chromium with Clang on Linux grew from 4493185726 bytes with r143096 to 6105527902 bytes with r143097. Compile time increased ~5%.
I have both builds stashed away. Please let me know if there are any object dumps, etc. that I can upload to help debug this.
The text was updated successfully, but these errors were encountered: