4 ms·

9% faster, 15% bigger. I'll take that!

• DannyBee 10y ago
  FWIW: This is actually not that great, but it's a good start. 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.
  • kevincox 10y ago
    If I'm understanding the increase is mostly due to the "debugging" info that is added, not necessarily due to more code.
    • DannyBee 10y ago
      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)
      • sythe2o0 10y ago
        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.
        • DannyBee 10y ago
          "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.
• bmm6o 10y ago
  Increased sizes lead to less effective use of instruction caches. Different use cases will be impacted differently by that, so it's worth profiling your particular application, at least until the size overhead comes down.