[preprocessor] include speed question
Hello all, I have a general question about what's the best way to include files that results in faster compilation time. In my example, I have *a lot* of files that use different parts of Boost.Preprocessor. Each header includes the specific Boost.Preprocessor headers that it needs. As a results the same Boost.Preprocessor header and #included many times (50+?) even if the including has no effect after the first inclusion. Furthermore, at the end essentially all Boost.Preprocessor header get included. This way is more module in that each single file includes all the headers that it needs. But, does that slow down compilation? Would it be faster to just #include <boost/preprocessor.hpp> just once into a front-end header that then includes all my single header files? (Maybe with modern compilers and file-systems this makes no difference?) Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-preprocessor-include-speed-question... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 10.05.2012, at 18:30, lcaminiti wrote:
This way is more module in that each single file includes all the headers that it needs. But, does that slow down compilation? Would it be faster to just #include <boost/preprocessor.hpp> just once into a front-end header that then includes all my single header files? (Maybe with modern compilers and file-systems this makes no difference?)
GCC and Clang, and probably most compilers, recognize include guards for what they are and won't even look at the file for subsequent inclusion directives. So redundant includes there should take basically no time. MSVC doesn't implement this optimization AFAIK - there you have to use the #pragma once directive to achieve this effect. Otherwise the compiler will open and read the file again, even if it is just to scan past the entire content. Sebastian
On 5/10/2012 9:30 AM, lcaminiti wrote:
I have a general question about what's the best way to include files that results in faster compilation time.
In my example, I have *a lot* of files that use different parts of Boost.Preprocessor. Each header includes the specific Boost.Preprocessor headers that it needs. As a results the same Boost.Preprocessor header and #included many times (50+?) even if the including has no effect after the first inclusion. Furthermore, at the end essentially all Boost.Preprocessor header get included.
This way is more module in that each single file includes all the headers that it needs. But, does that slow down compilation? Would it be faster to just #include<boost/preprocessor.hpp> just once into a front-end header that then includes all my single header files? (Maybe with modern compilers and file-systems this makes no difference?)
This is the same-old-same-old and applies to everything, not just the pp-lib. The way to solve this is with some sort of module mechanism in the language--which is difficult to do correctly. Regarding boost-pp specifically, even if you did include <boost/preprocessor.hpp>, the library itself pulls in specific dependencies. I personally _never_ use these "group" headers with pp stuff (and try to avoid it with non-pp stuff). The real reason for that is not compilation performance but to minimize physical dependencies and minimize the visibility of names (another potential benefit of a module mechanism). I'm not a terribly big fan of auto-dependency generation schemes. I actually prefer to make an explicit choice about whether to introduce a dependency. On the other hand, I do like automatically *verified* but explicit dependencies. For a build system, what I'd actually want (in addition to the usual) is that 1) there is a means to specify transitive dependencies such as includes--makefiles are horrible at this without using some form of automatically generated dependencies which cannot always be achieved, 2) a means of specifying iterative bootstrapped scenarios (e.g. LaTeX), and 3) each build action is executed in an environment where only the specified dependencies "exist"--which would provide the verification. Regards, Paul Mensonides
participants (3)
-
lcaminiti -
Paul Mensonides -
Sebastian Redl