Reduce compile times

[nilsdeppe]

Reduce compile times

[kidder]

Partially addressed in #176

[mar-celine]

Addressed again in #441

[nilsdeppe]

Link time is addressed in #475

The major known outstanding problem is the libstdc++ implementation of std::tuple

[nilsdeppe]

We use IWYU now to help with this

[nilsdeppe]

Still need to:

• optimize PCH
• not use std::tuple
• Split actions into tpp files that are compiled separately. For this we need to make sure we don't create db::DataBox because the construction of Deferred classes is (very surprisingly!) expensive.
• Improve compilation time of Deferred and db::create. Most expensive part of db::create is by far the Deferred construction, second most is the splitting out of compute items and simple items from the list of all items. We should probably keep those separate and pass in two typelists as template parameters to db::DataBox

[nilsdeppe]

#4023

[nilsdeppe]

@macedo22 has done some profiling and it looks like option parsing is taking up a huge amount (50%) of compilation resources in executables

[nilsdeppe]

#5104

[nilsdeppe]

We recently found that src/NumericalAlgorithms/Spectral/Projection.cpp compiles quite slowly. This is most likely because of how we've implement StaticCache, which is recursive and does a lot of tensor products of different functions. We could:

• Store a std::vector of function pointers and have a function that maps the arguments to operator() into the vector. Each of the functions whose pointers are in the std::vector must handle the static-ness to guarantee thread safety internally. The std::vector is created in the constructor of the StaticCache.
• We might be able to move the template parameters from StaticCache onto the constructor in this case.
• We could try use variadic auto to do this. The computer function is whose function pointers are stored in the std::vector. E.g.

template <auto... Args>
const T& computer() const {
  static T blah = generator_(Args...);
  return blah;
}

• brigand likely has some facilities of doing tensor products of lists that we could hook into and is likely much faster than what we are doing now.

discussed with @wthrowe and @kidder