Estimating the penalty of including Boost libraries

submited by

Style Pass

2021-06-30 22:30:04

TL;DR; I’ve made a (yet another) simple repo and a table on its’ wiki to estimate the build penalty when including boost headers.

Boost libraries have a mixed reputation in the C++ community. There are a lot of exceptional quality libraries with algorithms and data structures missing in the standard library. One might even say, that the boost is kind of a playground to test something before it can get into the standard (smart pointers are one of the many examples). On the other hand, boost gets heavily criticized for overcomplication, custom build environment and a lot of cross-connections. Don’t forget the NIH syndrome, which once forced me to re-implement the static_vector class.

C++ is (in)famous for it’s compilation times, especially for the template-heavy code. That got me thinking, how bad is the penalty for including the boost headers? So I’ve came up with a simple CMake script, which creates a trivial source file with a single #include directive, repeated N times for all the main boost headers I could reach:foreach(header ${HEADERS_TO_PROCESS}) string(REPLACE "." "-" filename_preliminary ${header}) string(REPLACE "/" "-" header_name ${filename_preliminary}) set(filename "${CMAKE_CURRENT_LIST_DIR}/${header_name}_main.cpp") file(WRITE ${filename} "#include <${header}>\n int main() { return 0; }\n") set(executable_name "Check${header_name}") add_executable(${executable_name} ${filename}) target_compile_options(${executable_name} PUBLIC -ftime-trace) target_link_libraries(${executable_name} pthread stdc++ stdc++fs) endforeach()

Then I used the -ftime-trace clang (9.0+, IIRC) switch to generate JSON report on the compilation times. I decided to settle for the whole .cpp compilation time since it’s easier to drag it from the report.