4 ms·

The really big (obvious) missing comparison here is with clang's pre-compiled headers code, and also using ccache. I'm tempted (as they are providing no eviden

The really big (obvious) missing comparison here is with clang's pre-compiled headers code, and also using ccache. I'm tempted (as they are providing no evidence otherwise) that this is snake-oil -- they are just calling stuff which already exists in clang, maybe with a bit of ccache on top. I'll be happy to be proved wrong.

kazinator 11y ago
ccache caches the entire translation unit to prevent the recompilation of a new .o file. It doesn't prevent the inclusion of all the header files; it still has to process all that material to determine the hash. Then if the translation unit has changed, it is compiled, conventionally. Header file preprocessing is about having some faster representation of included material which can be loaded instead of scanning header files. This can be used even when dependent files change.
IshKebab 11y ago
I don't think this is snake oil. The reasons that are typically given for not automatically pre-compiling headers (we're not talking about manually specified pre-compiled headers here) can all be worked around. For example, some might say that you can't automatically cache headers because of code like this: // file1.cpp #include "foo.h" // file2.cpp #define float double #include "foo.h" But if you're a bit clever about it you should be able to cache opportunistically and then detect if your cache is invalidated.
- yrnkrn 11y ago
  I am the prinicipal developer of zapcc. We have added a FAQ http://www.zapcc.com/faq/ http://www.zapcc.com/faq/ and more tech details in the cfe-dev mailing list http://lists.cs.uiuc.edu/pipermail/cfe-dev/2015-May/043174.html http://lists.cs.uiuc.edu/pipermail/cfe-dev/2015-May/043174.h... To the point, zapcc will not reprocess foo.h. This is a limitation. However, zapcc does deal with templates instantiations and such correctly and fast, such as boost various libraries, Eigen and LLVM source code.

kazinator 11y ago

ccache caches the entire translation unit to prevent the recompilation of a new .o file. It doesn't prevent the inclusion of all the header files; it still has to process all that material to determine the hash. Then if the translation unit has changed, it is compiled, conventionally. Header file preprocessing is about having some faster representation of included material which can be loaded instead of scanning header files. This can be used even when dependent files change.

IshKebab 11y ago

I don't think this is snake oil. The reasons that are typically given for not automatically pre-compiling headers (we're not talking about manually specified pre-compiled headers here) can all be worked around. For example, some might say that you can't automatically cache headers because of code like this: // file1.cpp #include "foo.h" // file2.cpp #define float double #include "foo.h" But if you're a bit clever about it you should be able to cache opportunistically and then detect if your cache is invalidated.

yrnkrn 11y ago
I am the prinicipal developer of zapcc. We have added a FAQ http://www.zapcc.com/faq/ http://www.zapcc.com/faq/ and more tech details in the cfe-dev mailing list http://lists.cs.uiuc.edu/pipermail/cfe-dev/2015-May/043174.html http://lists.cs.uiuc.edu/pipermail/cfe-dev/2015-May/043174.h... To the point, zapcc will not reprocess foo.h. This is a limitation. However, zapcc does deal with templates instantiations and such correctly and fast, such as boost various libraries, Eigen and LLVM source code.