Hacker News Reader

Comment by Joker_vD | Hacker News Reader

While I truly appreciate the effort... what the hell exactly goes into the Chromium's PDB file that it barely fits on a DVD-ROM? I am willing to bet that the executable and the source code combined together would take less space, so what is even in there?

View on HN

> what the hell exactly goes into the Chromium's PDB file that it barely fits on a DVD-ROM?

Debug symbols in general tend to be very big. You need to be able to map each instruction in the binary to a line of code. You can expect a compiler to break each line of code into several instructions, and you can also expect that the instructions are out of order and interleaved with neighboring lines of code. So each instruction will need its own unique entry.

> I am willing to bet that the executable and the source code combined together would take less space,

     ~ $ ll -h /var/cache/distfiles/chromium-110.0.5481.177.tar.xz 
    -rw-rw-r-- 1 portage portage 1.6G Feb 22 11:02 /var/cache/distfiles/chromium-110.0.5481.177.tar.xz
     ~ $ tar -xaf /var/cache/distfiles/chromium-110.0.5481.177.tar.xz
     ~ $ du -sh chromium-110.0.5481.177/
    13G chromium-110.0.5481.177/

Excuse me? On Windows, "C:\Program Files (x86)\Google\Chrome" takes 603 MiB only — and it contains a 295 MiB file called "chrome.7z" inside an "Installer" subdirectory. What does Linux distribution contains that takes the rest of the space?

That's not the Linux distribution, it's the source code. Straight from Google.

https://commondatastorage.googleapis.com/chromium-browser-of...

The compiled binary is much smaller:

     ~ $ du -h /usr/lib64/chromium-browser
    16K /usr/lib64/chromium-browser/MEIPreload
    360K /usr/lib64/chromium-browser/locales
    383M /usr/lib64/chromium-browser

Huh, so the size comparison actually goes "compiled binary" < "debug symbols" < "source code", interesting to know, thanks.

Debug symbols are often larger than the original source code though. The main culprit is C++ template expansions, which can get crazy long.

Love the use of distfiles for an in the spot demonstration, makes me miss Gentoo. I suppose functional package-manager users have similar files in their stores. Thanks for sharing.

It's not just Chrome. We (Sentry) handle a lot of native crashes and the amount of really large debug symbols went up in recent years. C++ template instantiations are a huge reason for it.

Rust generics are good at it too.

Absolutely and in some ways even worse. However Rust is in comparison with C and C++ a rather small player on our platform.

Web browsers contain a staggering amount of code, often linked into one huge binary so that LTCG can happen. They are basically an OS kernel+drivers+user space bundled into one.

If I had to guess, symbols for a lot of template instantiations.

Because chromee is a) a project with a lot of code b) a lot of the code is templates and c) chrome provides full debug symbols which includes all symbol names, type information and source code line numbers.

And local variables, including tracking where they are stored at various points in a function

I don't know literally a single thing about the PDB format, but assuming it at least somewhat similar to DWARF, it's REALLY easy to get an explosion of symbols in there, especially if you're looking at individual object files.

A clean checkout of chromium is 5 GB (excluding the .git folder) by itself, the symbols will of course be larger.

C++ templates can result in huge symbol names, especially if you're using them for complex metaprogramming, which I assume Chrome is (especially for stuff like the JavaScript engine). But as another commenter alluded to, constexpr might help with this a little - if people choose to use it.

Reply on news.ycombinator.com