Is around 4-5% larger with debug info, and that's a single trivial C program with a single call, and only build in types.
WebKit is largely C++, so a fairly trivial C++ program (that has no function):
template <typename T> struct MyFoo {
T m_field;
template <typename U> void add(MyFoo<U> rhs)
{
m_field += rhs.m_field;
}
};
Has a 10% size difference in size between deployment style builds and builds with debug info.
As the code size increases that amount of information needed in debug builds starts getting very large, as the description of classes and functions starts getting even larger than pure C versions.
The size of a debug build can vary quite a lot, as there are different forms of debug info, most commonly stabs or DWARF (and DWARF2). But even these are fairly bad in terms of space efficiency (stabs is evil), mostly as there isn't any real reason for focusing on that - fairly "trivial" space optimizations aren't implemented at all which means there are huge amounts of duplicated information, and the debug formats aren't really C++ aware, so each instantiation of a template results in a complete duplication of all the data describing it.
It would be nice if these problems could be fixed (eg. debug info that's aware of templates is the biggest problem in webkit), but other places where information is duplicated needlessly is also fairly crappy. But there's stuff pushing back against such optimizations:
Debug symbols are primarily used in _debug_ builds, while debugging. When you're debugging you want the build to be as fast as possible, and any work the compiler+linker do to reduce debug data size is going to add to compilation time, which everyone will then complain about.
(Of course without SSDs we'd have probably reached the point we're writing such large amounts of data out would be taking longer than reducing the size and writing less data in the first place...)
Even something trivial like #include <stdio.h>
int main(int argc, char argv) { printf("Hello world\n"); return 0; }
Is around 4-5% larger with debug info, and that's a single trivial C program with a single call, and only build in types.
WebKit is largely C++, so a fairly trivial C++ program (that has no function): template <typename T> struct MyFoo { T m_field; template <typename U> void add(MyFoo<U> rhs) { m_field += rhs.m_field; } };
int main(int argc, char argv) { MyFoo<float> f; f.m_field = 1.5; MyFoo<int> i; i.m_field = 1; MyFoo<double> d; d.m_field = 0; d.add(i); d.add(f); }
Has a 10% size difference in size between deployment style builds and builds with debug info.
As the code size increases that amount of information needed in debug builds starts getting very large, as the description of classes and functions starts getting even larger than pure C versions.
The size of a debug build can vary quite a lot, as there are different forms of debug info, most commonly stabs or DWARF (and DWARF2). But even these are fairly bad in terms of space efficiency (stabs is evil), mostly as there isn't any real reason for focusing on that - fairly "trivial" space optimizations aren't implemented at all which means there are huge amounts of duplicated information, and the debug formats aren't really C++ aware, so each instantiation of a template results in a complete duplication of all the data describing it.
It would be nice if these problems could be fixed (eg. debug info that's aware of templates is the biggest problem in webkit), but other places where information is duplicated needlessly is also fairly crappy. But there's stuff pushing back against such optimizations:
Debug symbols are primarily used in _debug_ builds, while debugging. When you're debugging you want the build to be as fast as possible, and any work the compiler+linker do to reduce debug data size is going to add to compilation time, which everyone will then complain about.
(Of course without SSDs we'd have probably reached the point we're writing such large amounts of data out would be taking longer than reducing the size and writing less data in the first place...)