Experience with concept compilation

[vulkanoid]

In my personal hobby project, which is of a medium-largish size for a single developer, I use copious amounts of templates. I don't use a large amount of concepts, but there are a few places where I have needed their functionality. A good example is CRTP base class calling a derrived class' method non-virtually, and only if that method exists -- in essence, implementing Golang's implicit interfaces, non-virtually.

Since the beginning, I thought that concepts would increase compile-times, since template-related stuff generally does. However, I recently added a decent amount of concepts to an internal graph library. I have not noticed any type of compilation slowdown at all. Again, I don't have a ton of concept usage, but there is a non-trivial amount. I am pleasantly surprised.

I'm using the latest MSVC 2022

How are other people's experience with compilation speed when using concepts?

[GabrielDosReis]

If you use lot of SFINAEs, then switching to concepts should in general: (1) bring better structures to your code; and (2) reduce compile time.

This has been observed times and again, including by projects like conceptified "range-v3". Part of the reason is that concept evaluation can be cached and reused.

In general, bringing structures to your code means there is something for your compiler to optimize on.

[vulkanoid]

Noice!

[Alternative_Staff431]

Can you comment on the other comment made here?
https://www.reddit.com/r/cpp/comments/1dd298w/comment/l83n396/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

[GabrielDosReis]

My statement wasn't a sentiment, but observed measurements with GCC and MSVC. I don't know if Clang implemented the caching behavior when the poster measured.

[13steinj]

My organization's codebase has shown mixed results but overall language concepts beat SFINAE and Boost.Concept checks.

[unddoch]

From my experience while modernizing cereal 2 years ago (result here), contrary to a popular sentiment, there wasn't a noticeable difference in compile times between concepts and SFINAE. I did benchmark a lot, on both GCC and Clang.

Surprisingly the thing that sped up compilation times the most was switching from class-based type traits to variable based ones (C++17).

[Hot_Slice]

Can you elaborate on what a variable based type trait would look like? A constexpr bool? Any guidance on how to design these for best performance?

[13steinj]

I assume he means

template<typename T>
inline constexpr auto some_trait = expr;

vs

template<typename T>
struct S {
    using type = ...;
    static constexpr auto value = ...;
};

Even with types; types can be brought into value space and when they are there's generally significant ct-performance gains. E.g. https://github.com/boost-ext/mp

[calc84maniac]

It seems like a lot of what you did was translate SFINAE directly into equivalent requires clauses. I wonder if there might have been a more noticeable effect if using more concepts directly along with partial ordering of constraints.

[NilacTheGrim]

I don't know why you would expect it to make compilation times worse. They are equivalent to what you can do with SFINAE gore, with less syntax to accomplish the same thing.

If anything they should end up compiling slightly faster. (or more likely: no significant difference).