[libcxx-commits] [PATCH] D104980: [libcxx][NFC] replaces `<utility>` includes with specific headers

[Hans Wennborg via Phabricator via libcxx-commits]

hans added a comment.

>> However, since there is very little benefit to minimizing the headers if nobody's going to turn on that `LEAN_AND_MEAN` flag, I'm not sure. Instead, here's what I think would be best:
>
> Someone from the Chrome toolchain team sent me an email this morning asking if we can trim our headers, since their include graph blames our user-facing headers as a huge build time sink. My news to them about our current stalling left a bad taste in my mouth, but I was inspired by something that they said about D90072 <https://reviews.llvm.org/D90072> to think creatively, and then remembered `WIN32_LEAN_AND_MEAN`. Since they reached out to me, this has gone from "I think this is a space to improve" to "there is a customer requesting something in this space". If they like the idea, I think it's worth entertaining, since Chrome takes //forever// to build. I've asked someone from that team to chime in as well.

If there were a `LIBCPP_LEAN_AND_MEAN` flag which reduced the header sizes meaningfully, we'd certainly use it.

In order to enable it, having Clang diagnostics with good fixit hints would certainly help, but we could probably do without it too with some scripting, so don't block on that on our account.

In D104980#2881239 <https://reviews.llvm.org/D104980#2881239>, @Quuxplusone wrote:

>> Someone from the Chrome toolchain team sent me an email this morning asking if we can trim our headers, since their include graph blames our user-facing headers as a huge build time sink.
>
> Compared to all the other stuff in a big project like Chrome, blaming libc++ surprises me. Are they claiming that Chrome builds faster against libstdc++, then? Any chance of getting them to go public with their measurements? And they're blaming specifically the //size// of the headers (including, I should add, the disk traffic from opening and closing all these little files), not anything about the actual contents/implementation? E.g. I myself have done a blog post titled "37% of HyperRogue's compilation time is due to std::function" <https://quuxplusone.github.io/blog/2019/01/06/hyper-function/> (2019-01-06), but that's nothing to do with disk traffic nor compiler-internal data structures, and everything to do with the bloated `std::function` API/ABI itself.

We're not blaming our slow builds on libc++, but we're looking everywhere we can, and if the libc++ headers could be made slimmer, it would certainly help since we rely on many of them almost everywhere, and I'd expect it would be a win for other projects too.

The numbers we're looking at are public, and can be found here: https://commondatastorage.googleapis.com/chromium-browser-clang/include-analysis.html That doesn't measure compile time, but compiler input size. In other measurements we've seen a strong correlation between compiler input size and compile time. It's not surprising that libc++ headers are on top since they're included everywhere, but that also means there's a high chance slimmer libc++ headers would have measurable impact for us.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D104980/new/

https://reviews.llvm.org/D104980