https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jason at gcc dot gnu.org
--- Comment #20 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Giuseppe Ottaviano from comment #19)
> At Facebook we experienced a similar regression, compilation times more than
> doubled for several large C++ files.
> We found that the regression was mostly caused by r207240, specifically to
> the changes in bits/alloc_traits.h. Just reverting that file brought back
> build times almost to previous levels.
>
> By looking at GCC profiles, a disproportionate amount of time is spent in
> structural_comptypes and template_args_equal (which doesn't happen before
> the change). The revision only changes the way some traits are selected
> through SFINAE, specifically the pattern:
>
> template <typename T> enable_if<..., R>::type f();
>
> became
>
> template <typename T, typename = _Require<...>> R f();
>
> and _Require is just a wrapper around enable_if.
Jason, this is an interesting observation about where time is spent in the FE
for this common SFINAE technique. I use it for constructors, where there is no
return value on which to put the enable_if, and where adding an extra
constructor parameter with a default argument would change the signature (or be
impossible, due to the constructor being a variadic template).
Any chance this is low-hanging fruit and could be avoided fairly easily, or
should I stop using this technique in bits of the library that are compiled as
often as allocator_traits?
> I don't know why this change has such a large impact on compilation times,
> it would deserve some investigation. Other parts of the standard library
> might be affected by this.
Very probably, I have used that pattern widely.
> The regression might have been already solved in r225244, which uses yet
> another SFINAE pattern without extra template arguments, which I believe are
> the cause of the regression. However I haven't tested it yet.
That would be nice to know, because I now use that kind of void_t-style
constraint in a few places, and plan to use it more widely. My measurements do
show that using void_t-style constraints result in small but measurable
reductions in compile time and memory use.
