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 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: - live with the .o file size increase and look for ways to reduce .o file size that are unrelated to r143097. - revert my stringpool work entirely. - revert r143186, an optimization that LLDB makes uses of. It would decrease file size by directly inlining some of the strings and therefore not require so many relocations. This is what GCC does. LLDB asked for this change so that DIEs all have the same size, making the debugger faster. - remove all relocations for the string pool and force the linker to parse debug info to find indirect strings itself. This is a lot of work and would just increase link times (bad; links are serial, compiles are parallel). 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.
(In reply to comment #4) > 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. :) 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?
(In reply to comment #12) > 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.