In a very simplistic way, I understand:Compilation = Pre-processing + Parsing + Linking + ExecutableAll the macros and other such pre-processing directives are taken care at the Pre-processing stage itself. Suppose, if we have several macros in source code, then will they cause any significant time in pre-processing stage?To clarify, I am talking about the macros which are #defined in header file but are not #undefed in that same file for some or no reason.Due to its practicality, it will be helpful if anyone has any profiling info on this topic.
Does having so many macros (#define) increase compilation time due to prolonged pre-processing?
c++;c;macros;profiling;compilation
Today, the preprocessing is actually happening inside the compiler (e.g. inside the cc1plus executable started by g++ command). Use g++ -C -E to get the preprocessed form.Preprocessing and parsing is a well known art, and does not take that much time. However, the standard headers of C++11 (e.g. <vector> or <map>) are pushing a lot of stuff. For example, #include <vector> is pushing about ten thousand lines of code on GCC/Linux with GCC 5. This is one of the reasons why compiling C++ code is slow (another reason is that C++ being incredibly context sensitive, parsing it is slow: overloaded functions, naming ambiguity, etc...).Having many thousands of almost unused #define-d macros is not an issue today. (perhaps having millions of #define might be an issue; I leave you to try that) Look into the source code of GTK or of the Linux kernel for some example.The reason it is not a real issue today (on current laptops & desktops, with e.g. 8GBytes of RAM) is that it is mostly filling some symbol table, and these tables can routinely handle many hundred thousands symbols.Notice that optimizing compilers take lots of time in optimization. And C++ code practically needs to be optimized (in particular, because it has lots of trivial inlinable member functions, notably in template instantiation for standard containers, etc...). Even C code needs to be optimized (because current superscalar out-of-order multicore pipelined processors are really different from the processors of the previous century for which C have been designed).If you are curious about where the GCC compiler is spending its CPU time (see also this question) pass -freport-time to g++ (and also -Wall -O2 for example). If you are even more curious, customize your GCC compiler with MELT (but that requires understanding something about GCC internals, which takes weeks).Notice that C (not C++) compilation is fast for its preprocessing & parsing phases (the bulk of the CPU time happens in optimization passes; experimentally, with gcc -O2, the compilation time is proportional to the square of the size of the largest compiled function). If you don't care about optimized code you could even try the tinycc compiler (which compiles about ten times faster than GCC or Clang, but produces slow machine code).