Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Massive compilation time degradation when upgrading to libBoost 1.68 #76

Open
PiotrZSL opened this issue Nov 26, 2019 · 5 comments
Open

Comments

@PiotrZSL
Copy link

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 <[email protected]>
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:

1.72:  1m28.077s
1.69:  1m26.839s
1.68:  1m30.255s
1.67:  0m26.357s
1.66:  0m26.683s

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.

@akrzemi1
Copy link
Member

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() and flat_map(). Would this solution work for you?

@PiotrZSL
Copy link
Author

PiotrZSL commented Nov 29, 2019

Yes it would. But to be honest in project we are taking actions to get rid of boost::optional.

@MikeGitb
Copy link

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
Copy link
Author

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants