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

[Christopher Di Bella via Phabricator via libcxx-commits]

cjdb added a comment.

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?

No. Chrome isn't built against libstdc++ (I'm not sure if it's even possible). Granted, libstdc++ is out of scope.

> Any chance of getting them to go public with their measurements?

Good question, but I don't have an answer for you.

> 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" (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.

I'll also leave this question to the Chrome toolchain team to answer, but it seems to me that the little files are hardly a blip on the radar, and that a dominating factor is that we're (libc++) unnecessarily transitively including a //lot// more than we need to be.

>> I don't really like it any more than you do, but it's a user-visible knob with a very short life expectancy.
>
> User-visible features never //really// have short life expectancies. ISTR someone talking about "Hyrum's Law" on this very Phabricator instance, fairly recently... ;)

This won't end up being a Hyrumbug. Hyrum's law states that given a sufficiently large user base and enough time, anything that is observable eventually becomes the interface, even if it's intended to be an implementation detail, which will lead to breaks on anything that's public facing. In this case, we'd have a public-facing macro (so it's already exempt), that would be deprecated when it's no longer necessary (so users stop defining it), and even once we remove said deprecation notice, it won't break anyone. It'll just be a benign eyesore in some code.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104980