Compilation time analysis via ClangBuildAnalyzer

[vittorioromeo]

Trying to speed up compilation times a bit. The first step is an analysis using ClangBuildAnalyzer, which I ran over the entire repository, with tests and examples enabled.

ClangBuildAnalyzer output here:
https://gist.github.com/vittorioromeo/ab81ce00927149737398f97d3948b62e

Most of the time is spent in these instantiations, would be nice to try and optimize those:

**** Template sets that took longest to instantiate:
 71289 ms: sqlite_orm::internal::iterate_tuple<$> (2459 times, avg 28 ms)
 60327 ms: sqlite_orm::internal::serialize<$> (1782 times, avg 33 ms)
 51614 ms: sqlite_orm::internal::storage_t<$>::sync_schema (162 times, avg 318 ms)
 46721 ms: sqlite_orm::internal::storage_t<$>::sync_table<$> (270 times, avg 173 ms)
 36778 ms: sqlite_orm::internal::storage_t<$>::prepare<$> (797 times, avg 46 ms)
 36467 ms: sqlite_orm::internal::storage_t<$>::prepare_impl<$> (797 times, avg 45 ms)
 24957 ms: sqlite_orm::internal::storage_t<$>::create_table<$> (246 times, avg 101 ms)
 24890 ms: sqlite_orm::internal::storage_t<$>::select<$> (346 times, avg 71 ms)
 24793 ms: std::forward_as_tuple<$> (1914 times, avg 12 ms)
 21827 ms: std::tuple<$> (3978 times, avg 5 ms)
 18537 ms: std::__and_<$> (10567 times, avg 1 ms)
 11696 ms: std::_TupleConstraints<$>::__is_implicitly_constructible<$> (5385 times, avg 2 ms)
 10446 ms: sqlite_orm::internal::table_t<$>::for_each_column<$> (972 times, avg 10 ms)

[trueqbit]

Thank you, @vittorioromeo, any investigation, insights, ideas, and tests are appreciated!

Additionally to the ClangBuildAnalyzer, is the chrome://tracing tool helpful as well?

The compile times and resources required by the compiler have improved since v1.7. For v1.8 I have streamlined the entire template code machinery. The tuplification of the 'storage' implementation and the generalization of tuple filtering and iteration seem to have a positive effect on the resources required by the compiler.

As you have seen, I also tried to play around with a custom tuple (PR #1055). I learned that the standard tuple implementations are usually horrible (though clang/llvm use a non-recursive implementation as mentioned by Howard Hinnant), but I didn't notice any improvements in build times with the hana-based custom tuple, neither in my Visual C++ test environment, nor on appveyor. I didn't check the resource-consumption of the compiler.

We do have a few people that complained about insane build times or compiler resource exhaustion, which seem to be resolved:

• Clang compiler stuck and lots of memory are used when combining -O2 with -g #701
• Is there a workaround to compile a big table in 4GB memory device for release version #1038
• Crash when using a lot of tables #1083