4 ms·

For C++, if you have many library headers used repeatedly in many source files, the number 1 suggestion ought to use a precompiled header (which you write yours

For C++, if you have many library headers used repeatedly in many source files, the number 1 suggestion ought to use a precompiled header (which you write yourself with commonly used library headers but none of your application headers). It was mentioned on that page but a bit buried and OP replaced a whole dependency before trying it. I don't think the same thing would work for Rust because, unlike C++, it doesn't need to constantly reparse files in its depedencies - essentially it already has them automatically. C++ is aiming to move that way in future with modules. Edit: I just tried turning off precompiled header on one of our larger programs that's heavy on Boost and a couple of our other libraries, and it increased build time from 2:16 to 10:52 (that's minutes and seconds) after fixing a few missing #includes that were covered by the precompiled header.

silon42 6y ago
Precompiled headers are a workaround when you can't modularize your project / headers files. But to use them you commit to the wrong way, including everything the same way everywhere.... what you should do is include only minimal stuff from the headers, and prefer to include most dependencies only in implementation.
- MaxBarraclough 6y ago
  So things would be better if Boost.Signals2 weren't header-only? Makes sense.
- quietbritishjim 6y ago
  > Precompiled headers are a workaround when you can't modularize your project / headers files. This is technically true but misleading - the whole nature of C++ means that you can't modularize your project / headers in a way that avoids transitively including lots of headers. There's two reasons for this: * Lots of Boost (and other library) types are vocabulary types - that's often the whole point of using them in the first place. If my class has a public method that returns a boost::optional<T> or boost::flat_map<K, V> then there's no way to avoid transitively including the relevant Boost headers in my header files. * Lots of Boost stuff is templated so the implementation has to go in the header, which means the transitive dependencies on other parts of Boost have to be included in the header, even they're only used in the implementation of the Boost class that you're directly use. The heavy templating is a result of the previous point - vocabulary types often need to be templated in order to be useful in many different situations.
  - pjmlp 6y ago
    Which is why many companies shy away from Boost and from libraries that do clever template meta-programming.
    - quietbritishjim 6y ago
      Indeed, but it's just ignorance driving that. You end up with three choices: * Use libraries like Boost and waste developer time waiting for compilation. * Avoid libraries like Boost and waste developer time re-implementing functionality (but then you have the same problem anyway) or suffering from not having that functionality available to them. * Use libraries like Boost and spend a small one-time developer cost turning on precompiled header files in your build system.
      - deleted 6y ago
        [deleted]
      - mmm_grayons 6y ago
        Boost is a pain to compile, sure, but a bit of a necessary evil for anything C++. Threadrippers are dirt cheap compared to developer time and compilation is embarrassingly parallel. Just by devs 32-core boxes and be done with it.
        pjmlp 6y ago
        Except that on the projects I have been consulting, the last time I actually coded on a desktop was around 2006. And most customers nowadays just have IT throw a VM to externals. You're not getting Threadrippers from these kind of companies.
  - Rexxar 6y ago
    You just have to use forward declaration headers in you headers. For your two examples : -> flat_map: https://www.boost.org/doc/libs/1_67_0/boost/container/container_fwd.hpp https://www.boost.org/doc/libs/1_67_0/boost/container/contai... -> optional: https://www.boost.org/doc/libs/1_67_0/boost/optional/optional_fwd.hpp https://www.boost.org/doc/libs/1_67_0/boost/optional/optiona...
usefulcat 6y ago
It seems to depend a lot on the particular compiler. I know that in the past, precompiled headers made a huge difference with MSVC (and maybe they still do, but I haven't used it in some years at this point). Today, I have a medium-sized c++ project that uses Linux, gcc 9.2 and boost and I have yet to find any combination of headers that I can put in the precompiled header file and see any reduction in compile times, either for a full build or an incremental build.
- quietbritishjim 6y ago
  Hmm, that is interesting... You're absolutely right, the program I was compiling is a Visual Studio program. (The code is actually cross-platform, partly thanks to the use of Boost, but for historical reasons it only has a Windows build system in the form of Visual Studio projects.) I'd definitely like to try my experiment again with GCC or clang at some point.

silon42 6y ago

Precompiled headers are a workaround when you can't modularize your project / headers files. But to use them you commit to the wrong way, including everything the same way everywhere.... what you should do is include only minimal stuff from the headers, and prefer to include most dependencies only in implementation.

MaxBarraclough 6y ago
So things would be better if Boost.Signals2 weren't header-only? Makes sense.
quietbritishjim 6y ago
> Precompiled headers are a workaround when you can't modularize your project / headers files. This is technically true but misleading - the whole nature of C++ means that you can't modularize your project / headers in a way that avoids transitively including lots of headers. There's two reasons for this: * Lots of Boost (and other library) types are vocabulary types - that's often the whole point of using them in the first place. If my class has a public method that returns a boost::optional<T> or boost::flat_map<K, V> then there's no way to avoid transitively including the relevant Boost headers in my header files. * Lots of Boost stuff is templated so the implementation has to go in the header, which means the transitive dependencies on other parts of Boost have to be included in the header, even they're only used in the implementation of the Boost class that you're directly use. The heavy templating is a result of the previous point - vocabulary types often need to be templated in order to be useful in many different situations.
- pjmlp 6y ago
  Which is why many companies shy away from Boost and from libraries that do clever template meta-programming.
  - quietbritishjim 6y ago
    Indeed, but it's just ignorance driving that. You end up with three choices: * Use libraries like Boost and waste developer time waiting for compilation. * Avoid libraries like Boost and waste developer time re-implementing functionality (but then you have the same problem anyway) or suffering from not having that functionality available to them. * Use libraries like Boost and spend a small one-time developer cost turning on precompiled header files in your build system.
    - deleted 6y ago
      [deleted]
    - mmm_grayons 6y ago
      Boost is a pain to compile, sure, but a bit of a necessary evil for anything C++. Threadrippers are dirt cheap compared to developer time and compilation is embarrassingly parallel. Just by devs 32-core boxes and be done with it.
      - pjmlp 6y ago
        Except that on the projects I have been consulting, the last time I actually coded on a desktop was around 2006. And most customers nowadays just have IT throw a VM to externals. You're not getting Threadrippers from these kind of companies.
- Rexxar 6y ago
  You just have to use forward declaration headers in you headers. For your two examples : -> flat_map: https://www.boost.org/doc/libs/1_67_0/boost/container/container_fwd.hpp https://www.boost.org/doc/libs/1_67_0/boost/container/contai... -> optional: https://www.boost.org/doc/libs/1_67_0/boost/optional/optional_fwd.hpp https://www.boost.org/doc/libs/1_67_0/boost/optional/optiona...

usefulcat 6y ago

It seems to depend a lot on the particular compiler. I know that in the past, precompiled headers made a huge difference with MSVC (and maybe they still do, but I haven't used it in some years at this point). Today, I have a medium-sized c++ project that uses Linux, gcc 9.2 and boost and I have yet to find any combination of headers that I can put in the precompiled header file and see any reduction in compile times, either for a full build or an incremental build.

quietbritishjim 6y ago
Hmm, that is interesting... You're absolutely right, the program I was compiling is a Visual Studio program. (The code is actually cross-platform, partly thanks to the use of Boost, but for historical reasons it only has a Windows build system in the form of Visual Studio projects.) I'd definitely like to try my experiment again with GCC or clang at some point.