iana added a comment. In D158709#4617295 <https://reviews.llvm.org/D158709#4617295>, @aaron.ballman wrote:
> I'm a bit concerned about the impact on (non-modules) build time performance. > This splits stddef.h and stdarg.h into needing to open 14 different files > instead of 2. Hopefully that's not a lot of overhead, but given that stddef.h > is included in approximately every TU and that sometimes external forces > cause files to be slow to open (network drives, AV software, etc), I think we > should be cautious and measure the impact. I also really do not like how > poorly this scales -- the fact that this is only needed for these two files > helps a bit, but this is a lot of C++-specific hoops to jump through for C > standard library headers. This is in support of clang modules, not C++ modules. The plan is to make modules like this. module _Builtin_stddef [system] { textual header "stddef.h" explicit module max_align_t { header "__stddef_max_align_t.h" export * } explicit module null { header "__stddef_null.h" export * } ... } I do agree it's a bit of a file explosion, but I can't really think of any better alternatives. It's tough to measure build time performance impact. If you have a slow enough file system (and the fs on our builders at Apple is quite slow), and you aren't using modules or pch's, and you have quite a lot of source files, then probably this would be noticeable? I still don't know what we could really do about it besides have `#if !__has_feature(modules)` and inline the contents in that case. That seems like a maintenance headache and a half though. I would hope that most sizable projects either use clang modules or pch's? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D158709/new/ https://reviews.llvm.org/D158709 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits