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

Binary sizes with debug info grew 35% after r143097 #11695

Closed
zmodem opened this issue Nov 7, 2011 · 16 comments
Closed

Binary sizes with debug info grew 35% after r143097 #11695

zmodem opened this issue Nov 7, 2011 · 16 comments
Labels
bugzilla clang worksforme

Comments

@zmodem
Copy link
Collaborator

@zmodem zmodem commented Nov 7, 2011

Bugzilla Link 11323
Resolution WORKSFORME
Resolved on Nov 30, 2011 17:34
Version trunk
OS Linux
CC @lattner,@echristo,@nico

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.

@nico
Copy link
Contributor

@nico nico commented Nov 7, 2011

The 5% slowdown is happening on mac as well. I didn't look at .o file size on mac.

@lattner
Copy link
Collaborator

@lattner lattner commented Nov 8, 2011

Nick, this has been pinned on your debug info change, can you take a look?

@llvmbot
Copy link
Collaborator

@llvmbot llvmbot commented Nov 8, 2011

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).

@llvmbot
Copy link
Collaborator

@llvmbot llvmbot commented Nov 9, 2011

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. :)

@lattner
Copy link
Collaborator

@lattner lattner commented Nov 9, 2011

I'll ask Greg about r143186

@llvmbot
Copy link
Collaborator

@llvmbot llvmbot commented Nov 9, 2011

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?

@llvmbot
Copy link
Collaborator

@llvmbot llvmbot commented Nov 9, 2011

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.

@echristo
Copy link
Contributor

@echristo echristo commented Nov 9, 2011

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...

@nico
Copy link
Contributor

@nico nico commented Nov 9, 2011

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.

@zmodem
Copy link
Collaborator Author

@zmodem zmodem commented Nov 9, 2011

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.

@llvmbot
Copy link
Collaborator

@llvmbot llvmbot commented Nov 9, 2011

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...

@echristo
Copy link
Contributor

@echristo echristo commented Nov 10, 2011

Nick raises a good question, did you guys see a decrease in size for the final linked binary?

@zmodem
Copy link
Collaborator Author

@zmodem zmodem commented Nov 10, 2011

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.

@lattner
Copy link
Collaborator

@lattner lattner commented Nov 10, 2011

Wow, great. This sounds like "behaves correctly" then.

@llvmbot
Copy link
Collaborator

@llvmbot llvmbot commented Dec 1, 2011

Agreed, let's close this bug. There are other reasons our .o files are so large, but we should attack those independently.

@echristo
Copy link
Contributor

@echristo echristo commented Dec 1, 2011

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.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
@Quuxplusone Quuxplusone added the worksforme label Jan 20, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla clang worksforme
Projects
None yet
Development

No branches or pull requests

6 participants