aaron.ballman added a comment. In D158709#4617783 <https://reviews.llvm.org/D158709#4617783>, @iana wrote:
> 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. Ah, good to know, thank you! > 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 possibly 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? Yeah, measuring file system impacts is always tricky. :-( The reason I'm concerned is actually because a fair number of projects explicitly don't use PCH or Clang modules (or C++ modules), especially in C. Because of how fast compilations go in C, it's possible that the extra filesystem overhead really will be noticeable by users. However, I also can't think of a way around this in code... At a high-level (not just for this patch, but for the entire series): is this need specific to your downstream or is this a more general need? e.g., should this complexity be kept downstream until we've got a second platform needing it? 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
