Huge size of nacl_helper file

[Shanfeng Cheng]

I am building the official release version of Chromium m55 under ubuntu 14. The size of the nacl_helper file is 500MB+. Something must be wrong with it since it since the same file in the official chrome archive is 2MB. Anyone experience similar issue? The args I used to build is like this:

is_component_build = false
is_debug = false
target_cpu = "x64"
is_official_build=true
proprietary_codecs=true
ffmpeg_branding="Chrome"

Is there anything else that I miss here? 

Thanks a lot for help!

---

Shanfeng Cheng

[Shanfeng Cheng]

Actually, it is more than just the size of nacl_helper. The chrome executable file is also as huge as 3GB. 

---

Shanfeng Cheng

[Primiano Tucci]

Hmm those gn args look reasonable to me. I know that it is a silly question but did you check that you don't have some typo in your cmds, so you are really building what you are gn-ing? 

Chrome being 3gb means that you got full symbols baked in.

can you check whether symbol_level = 0 makes any difference? It shouldn't be needed (please let us know if it fixes)  but maybe we recently regressed some logic there? 

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Torne (Richard Coles)]

You should strip the binary before distributing it. Even if you set symbol_level=0 then there will still be unnecessary information in the binary (the actual symbol table, which isn't affected by symbol_level). I'm not sure if there's a gn flag to have the build system strip the binary for you, but you can do it with "strip --strip-unneeded"

[Shanfeng Cheng]

Setting symbol_level=0 explicitly does make the file a lot smaller. I thought symbol_level should have the default value of 1 or less in the official release build. 

---

Shanfeng Cheng

[Bruce]

Why would we want symbol_level of 1 or less in the official release build? Since this is the variation that we ship to customers it is crucial that we be able to diagnose crashes and do profiling. Doing these effectively requires having symbols. Debugging of debug builds is certainly easier, but it is not always sufficient. And, profiling of release builds is the only type of profiling that is guaranteed to be meaningful.

Now, we shouldn't be shipping those symbols to customers, and we shouldn't let code quality be impaired by generating symbols, but I believe that all of the toolchains that we use for developing Chrome can generate fully optimized code, and symbols, and the symbols can be stripped into a separate file so that we don't ship them.

I routinely profile and debug the release versions of Chrome which means that I routinely rely on having symbols. Recommended.

[Primiano Tucci]

please ignore my comment.

Thinking more on this, it makes perfect sense that we have symbols in official builds, as those are required to generate then the breakpad symbols that are used for crash reporting.

The only weird exception to all this is Android where we default to symbol_level=1. The only reason is  crbug.com/648948, i.e. ELF 32 not able to deal with binaries > 4 GB, and symbol fission not being supported by breakpad yet. % this, copy what Bruce said above.

[Torne (Richard Coles)]

Stripping the binary correctly will still reduce it even further, even if you are using symbol_level=0. You don't need to build with a reduced symbol_level (and generally shouldn't unless you are never going to care about any kind of debugging whatsoever, even generating stack traces from crashes).

[Shanfeng Cheng]

Here is the problem about it. If I don't set the symbol level for the official release build, somehow I believe symbol_level is set to full symbols and that makes linking extremely slow and demands huge amount of memory. After I change the symbol level to 1, the linking is a lot faster. 

---

Shanfeng Cheng

[Primiano Tucci]

Yup was about to reply about this. One big advantage of symbol_level=0 is that, if you don't require symbols, that makes building and linking way faster.

> Here is the problem about it. If I don't set the symbol level for the official release build, somehow I believe symbol_level is set to full symbols and that makes linking extremely slow and demands huge amount of memory. After I change the symbol level to 1, the linking is a lot faster. 

Agree with the analysis but I don't see why this is a problem. Just set symbol_level=0 in your gn args easy no?

[Torne (Richard Coles)]

symbol_level=1 is fine; it's still usable to generate the same stack traces, and to debug (just with some information missing), but is much smaller and faster to build. symbol_level=0 is generally not worthwhile; the additional size/time saving is actually pretty small and when you *do* have a crash you want to generate a stack for you'll be annoyed that you can't get useful information out of it ;)

You should strip your binary before distributing it no matter what symbol_level you build with.

[Shanfeng Cheng]

I meant if I don't set an explicit symbol level, I will run into linking speed problem. Adding a simple line into the args is not an issue. But I believe it would make sense to default symbol_level to 1 for official build if not explicitly set.

[Torne (Richard Coles)]

No, because official builds are where detailed symbol and debug information are most important to us: we keep this information so that we can use it to understand crash data from the field.

[Dirk Pranke]

torne@ is right; we want the defaults to be as simple as possible. To get an official build configuration, all you should need is to set is_official_build=true. We want to keep the second-guessing to a minimum.

-- Dirk