I strongly doubt this.
It doesn't say this in the preso, and ...
1. The compiler is a lot slower, which is usually from code growth and not debugging info growth. If the compiler is that much slower from debugging info growth, they have larger issues :)
2. Usually people do not include debug info sizes in binary sizes, because DWARF/et al info can be stripped and put alongside the binary (IE it doesn't even have to be part of the binary)
It does say this. One of the last slides says 4% of the additional size came from adding more debugging information, excluding anything to do with the new inlining.
"If I'm understanding the increase is mostly due to the "debugging" info that is added, not necessarily due to more code.
"
vs
" One of the last slides says 4% of the additional size came from adding more debugging information, excluding anything to do with the new inlining"
So no, it doesn't say that it's "mostly due", it says ~25% is due to debugging information.
1. The compiler is a lot slower, which is usually from code growth and not debugging info growth. If the compiler is that much slower from debugging info growth, they have larger issues :) 2. Usually people do not include debug info sizes in binary sizes, because DWARF/et al info can be stripped and put alongside the binary (IE it doesn't even have to be part of the binary)