24 ms·

Is it handling the 5% correctly or is it just a lot more optimization passes that make the difference?

• _a_a_a_ 3y ago
  That's a good question. I'd personally go with the last 1/2 of your sentence.
• ndesaulniers 3y ago
  I've spent a lot of time profiling clang when compiling the Linux kernel. For large C codebases, compile time is dominated by lexing and parsing, not optimization passes. Headers have become too crufty; they tend to only grow over time, resulting in an amplification attack on the lexer and parser. Lazy parsing is maybe interesting. There's a hazard related to the mangling of lambdas. Carbon has an interesting idea of not constructing an AST. I think we also need tools to help us automate header refactoring.
  • kzrdude 3y ago
    That's a surprise to me. That must be one epic mass of header files. It reminds me of the massive Fast kernel headers patchset by Ingo Molnar. I hope it got in. I don't know anything about it, just marvelled at the scope of it.
    • ndesaulniers 3y ago
      The profiler frequently surprises. Imagine 30 years of headers. They tend to grow and grow and become a tangled mess. Ingo's patch set did not. I asked what was being done to automate this so that we wouldn't backslide. I received no response. That said, I think that work is fascinating. I have an intern starting Monday that's going to start research into automating this.