Slow compilation times

[erplsf]

Greetings,

First I wanted to say - big thanks for such an amazing library! I already see many uses of it in the future.

But right now I've hit the brick wall basically - slow compilation times.
I've tried to build a custom dimension for Standard gravitational parameter (used in orbital mechanics) as shown in example here:
https://mpusz.github.io/units/use_cases/extensions.html#custom-derived-dimensions
My implementation of it is here:
https://github.com/erplsf/smok/blob/master/calc.hpp#L11:L27
Clion reports 27 seconds build time for this small project. I have a pretty modern CPU (Ryzen 2700x), and SSD.
Here's link to a report from running with g++ -Q (profiling information, gcc version 10) -> https://gist.github.com/erplsf/a5ddeb5e0a477601e4aa44b968738861

My main question is - is there something I can do to achieve reasonably compile times in "Debug/Development" mode?
Otherwise it kills the usage of the library for me and many potential other users, as it's impossible to prototype or rapidly develop with it.

But again, thanks for the great work, and I'm sorry if I've missed something obvious.

EDIT: Update the link to the code.

[JohelEGP]

For now, try this:

#include <units/physical/si/derived/speed.h>
// #include <units/physical/si/si.h>

#include <units/physical/si/si.h> includes all the SI system. Like you did here with #include <units/physical/si/derived/speed.h>, selectively include only what you use for "Debug/Development" mode.

[erplsf]

Thank you!
This cuts the compilation time from 27 to 6 seconds on average - which is still not comfortable but somewhat acceptable.

[mpusz]

Hi Andriy,

First of all, thanks for trying out the library and sharing your experience.

Yes, for now including a whole si.h has a sense only if you need most of the definitions there. Otherwise, it is preferred to include only what you need (IWYU). This library was designed with C++20 modules in mind. When we will switch to modules we believe this will no longer be an issue and having all definitions already in the library module will actually improve the compile-time performance (do it once and then reuse).

Said that we probably still have a lot of work to do to optimize compile times. I already did some optimizations based on vcperf and plan to do more. However, with the majority of work, we wait for clang to join the party of compatible compilers so we can use its great time-trace feature.

[erplsf]

Thank you!

I think I'll replace the library for now with raw double's, so I can rapidly test, and when I'm ready to release switch back to compile-time backed physical units.

Should we add a tip or/and warning to the users that they may encounter increased compilation time while we wait for modules?

EDIT: I've compared my compile times with or without the library - with (and only required units it's 6 seconds, without it it's 4 - so I decided to try to push myself further using this library.

[mpusz]

Please note that I recently added the following chapter to our docs: https://mpusz.github.io/units/framework/quantities.html#don-t-pay-for-what-you-don-t-use-compile-time-performance.

[mpusz]

Relates to #7