> Normal compiles instantiate items as determined by the > database. It is a known waste of compile time to not so > instantiate such things, as we know they will be > instantiated. So, the entire concept doesn't make much sense > to me, unless you only are only interested in the speedup > from those units that don't use any definitions. Now, if we > know that no definition is needed in a file, having it > disappear the definitions is enticing, but after you > benchmark it against pch, I suspect you'll wonder why you bothered.
Maybe... I think the 'big_header', which is required by template definitions, has a big impact here. And I find it hard to believe that excluding a big chunk of code from compilation results in no speed-up. Even when using precompiled headers, .pch files can get pretty big, and they must still be loaded, which takes time. Furthermore, compiler must keep all otherwise not required declarations/definitions in memory, which (I suppose) also takes some time. But (potential) compilation speed-up is just a side effect of this proposal. I apologize for overstating these speed benefits. The main point of this idea was to come up with a simple way to separate compilation of the code generated by template instantiations and their usage as much as possible (without actually implementing export). > > 1. Code in foo.cpp normally compiles without including big_header.h > > (from bar.tpp). This makes it impossible for foo.cpp to become > > inadvertently dependant on the code from big_header.h. > > One can already reap this benefit by the #ifdef/-D during > compilation, so I don't see any benefit. True. I've achieved (almost) the same effect by using sed on .rpo files (to add -D) and implementing proper dependencies in the makefile. But such approach is 'messy' and not practical for larger projects. > > 3. Definitions for the bar class template and the big_header are only > > compiled by collect2 during template instantiations. If bar<int> is > > commonly used in the code, compilation times would be significantly > > reduced. > > Reduced when compared to pch? With pch, all the common > things are instantiated once, and only once for the entire > project build. I suspect compilation time would not be reduced. I agree. Pch can be of big help here. But keep in mind that the size of the pch file also matters. And including a big_header (that you did not want to include in the first place) increases the pch file size. The main question I guess is: How difficult is to implement this -frepo2 functionality? If it is relatively simple and a patch is made, we can test all we want and then decide whether it is worth having it in the compiler or not. If it is difficult to implement, I believe it is not worth discussing it any further since the benefits of having this feature would probably not outweigh the implementation effort. Currently, despite my lack of compiler writing experiences, I still believe implementation should be trivial. Can some gcc guru confirm or negate this?
