9% faster, 15% bigger. I'll take that!
You should be able to get about 15-20% with about 3-5% binary increase size.
In fact, with ThinLTO, we often see that gain with binary size decrease from smart inlining choices.
(The heuristics for inlining take a very very long time to get right and tune)
The issue they will next hit is that inlining is going to make the compiler slower until they tune the heuristics well.
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)
So no, it doesn't say that it's "mostly due", it says ~25% is due to debugging information.