17

I'm using Boost Program Options, and it takes quite a while (10 seconds or even more) for compiling very small C++ code with it. It took 1 second compiling the code without boost library.

Any idea how to boost compilation/link time with boost library? It's cross platform, so I need to compile the code with Mac OS X/Linux/PC.

prosseek
  • 182,215
  • 215
  • 566
  • 871
  • 1
    Some parts of boost are very useful. Many components though look overengineered to me and got awful header dependencies just because they are implemented in headers only. So you end up recompiling boost code needlessly over and over, whereas a static or shared library would do nicely. – Maxim Egorushkin Feb 17 '11 at 15:55
  • 1
    Pretty much any compiler that's sufficiently modern to compile Boost also supports precompiled headers. Those are conceptually the equivalent of static libraries for header-only libraries. – MSalters Feb 17 '11 at 16:38
  • see here, http://www.boost.org/boost-build2/doc/html/bbv2/reference/precompiled_headers.html – Dilawar Jan 08 '12 at 22:43

2 Answers2

18

There isn't really much you can do beyond the usual tricks:

  • minimize dependencies: pull in only the Boost headers you really need, and use as specific headers as possible (many libraries have a single "master" header, such as boost/thread.hpp, but also a subdirectory with specific headers, like boost/thread/shared_mutex.hpp),
  • where possible, rely on forward declarations instead of including the entire header,
  • if possible, include the header only in a .cpp file. If you include it in a header, it has to be compiled every time a translation unit which includes that header is compiled. As a general rule of thumb, try to minimize the amount of code you have in headers,
  • all major compilers support precompiled headers. Use those to cut down compilation time,
  • experiment with unity builds. That may or may not be an advantage in your case.

And last, but not least, a final option is just to not use those specific Boost libraries.

I sometimes use certain Boost libs early on, out of convenience, and if/when compilation time gets too bad, I start looking at which libraries are expensive to compile, and which ones could be replaced by relatively simple code. Often, Boost is encumbered by the requirement to be so general. If you don't need something that works on 8 year old compilers, or which doesn't have to work across quite so many different types, then you may be able to write a simple replacement which works for you, and takes almost no time to compile.

Community
  • 1
  • 1
jalf
  • 243,077
  • 51
  • 345
  • 550
  • do you mean that compilation time is more valuable than reimplementing almost always very good Boost libraries? what about buying good CPU and SSD disk? also, your recommendation to use precompiled headers reduce this problem by ~80% in average. I think it's almost last one you list because it's not supported by really all compilers, only by all popular. `Boost Program Options` is typically used if your program requires more sophisticated input than just "arg1 arg2". In this case reimplementing it would be really time consuming option. – Andriy Tylychko Feb 17 '11 at 16:08
  • @Andy: no, I said it is *one* option you might consider in *some* cases. – jalf Feb 17 '11 at 17:30
1

I had good success with the compiler firewall idiom to reduce compile times.

Kevin
  • 24,871
  • 19
  • 102
  • 158
  • 2
    AKA Pimpl idiom. Pimpl is really good when the implementation does have strange/unusual/costly dependancies (like third party libraries that you don't need/want to expose in the API of the class). But bear in mind that it does incur costs, both in terms of another (often dynamically allocated) class instance for the Pimpl instance as well as complexity in code since most API of the class will be forwarded to the Pimpl class in some manner. – Meros Dec 06 '13 at 12:33