You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Massive compilation time degradation when upgrading to libBoost 1.68 #76
After upgrading to libBoost 1.68 our compilation time of our project (3.1 m lines) deceased dramatically from ~45 min to ~1h 10min.
Deeper investigation points to this commit:
commit 71d797b9ee132b381c2d4f3b5bcca2078b0a5062
Author: Andrzej Krzemienski <akrzemi1@gmail.com>
Date: Thu Jun 28 23:27:42 2018 +0200
added implementation and tests of flat_map()
Compilation time of single file changes from 0m35.891s to 1m29.625s.
Same file compiled under other versions:
Our project heavily utilize boost::optional.
Tested on GCC 6.4 and GCC 8.
Commenting out "flat_map" methods reduces compilation time from 1m31.631s to 0m35.455s, commenting out additionally "map" method reduces compilation time even more back to 1.67 level (0m27.002s).
Please optimize these functions or add ability to exclude them from compilation.
The solution I can thing of is to offer a macro that a user can choose to define, which disables the generation of member functions map() and flat_map(). Would this solution work for you?
Any idea, why those functions slow down compilation so much? Shouldn't template member functions only be generated by the compiler if they are used?
Or did that commit also add includes?
Changed the implementation for map and flat_map so that it does not rely on boost::result_of from Boost.Utility. This should speed up the compile times.
Activity
added implementation and tests of flat_map()
akrzemi1 commentedon Nov 29, 2019
Thanks for reporting this.
The solution I can thing of is to offer a macro that a user can choose to define, which disables the generation of member functions
map()andflat_map(). Would this solution work for you?PiotrZSL commentedon Nov 29, 2019
Yes it would. But to be honest in project we are taking actions to get rid of boost::optional.
MikeGitb commentedon Dec 21, 2019
Any idea, why those functions slow down compilation so much? Shouldn't template member functions only be generated by the compiler if they are used?
Or did that commit also add includes?
PiotrZSL commentedon Dec 21, 2019
Not 100% sure but it may be connected with debug symbols on GCC (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86964)
Some tests were also done on GCC 9, and there such big slow down isn't visible.
akrzemi1 commentedon Sep 13, 2024
Changed the implementation for
mapandflat_mapso that it does not rely onboost::result_offrom Boost.Utility. This should speed up the compile times.akrzemi1 commentedon Feb 18, 2026
How are the compilation times now?