[Bug c++/60976] New: Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2

[Bug c++/60976] New: Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2

[astellar at ro dot ru]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976

            Bug ID: 60976
           Summary: Compilation with G++ 4.9.0 is 2-3 times slower than
                    with 4.8.2
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: astellar at ro dot ru

Created attachment 32686
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32686&action=edit
g++ -v output for 4.8.2

Hello. After test upgrade from 4.8.2 to 4.9.0 I've noticed that compilation
takes significantly more time than before. g++ -v output for both compilers is
in attachments.

I've compiled the same file from internal project with following switches.
Debug build here, but it's the same problem with release flags:
-std=gnu++11 -fvisibility=hidden -Wall -Wextra -Winit-self -Winvalid-pch
-Wfatal-errors -Woverloaded-virtual -fvisibility-inlines-hidden -O0 -g -pipe
-fsanitize=address -ftime-report

Full ftime-report output for both compilers is in attachments. From what I see,
these steps take significantly more time than before:
- phase lang. deferred   : 1.22 usr for 4.8.2, 4.08 usr for 4.9.0;
- template instantiation : 1.44 usr for 4.8.2, 5.59 usr for 4.9.0.

Some other numbers are higher too, but these 2 have the largest increase. I'm
not sure how to create a reduced test case from this project, but I will try
something on Monday.

[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2

[astellar at ro dot ru]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976

--- Comment #1 from Chernyshev Viacheslav <astellar at ro dot ru> ---
Created attachment 32687
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32687&action=edit
g++ -v output for 4.9.0

[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2

[astellar at ro dot ru]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976

--- Comment #2 from Chernyshev Viacheslav <astellar at ro dot ru> ---
Created attachment 32688
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32688&action=edit
ftime-report for G++ 4.8.2

[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2

[astellar at ro dot ru]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976

--- Comment #3 from Chernyshev Viacheslav <astellar at ro dot ru> ---
Created attachment 32689
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32689&action=edit
ftime-report for G++ 4.9.0

[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2

[astellar at ro dot ru]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976

--- Comment #5 from Chernyshev Viacheslav <astellar at ro dot ru> ---
Created attachment 32696
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32696&action=edit
Test file used

[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2

[astellar at ro dot ru]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976

--- Comment #4 from Chernyshev Viacheslav <astellar at ro dot ru> ---
After a series of tests I'm pretty sure that it is not a problem of g++, but
libstdc++. Let me explain why do I think so.

First, I was not able to reduce real life case to reasonably small subset that
does not depend on external libs at least. So I've decided to test explicit
template instantiation of std::map for multiple combination of integer types as
key and value. File that I've used is attached as test.cpp.

Overall pattern was the same. After that I realized that results depend on
actual libstdc++ includes and I compare apples with oranges. So, I've used
these commands to get preprocessed dump:
- g++-4.8 -std=gnu++11 -O0 -E -P std_map.cpp > preprocessed_48.cpp
- g++-4.9 -std=gnu++11 -O0 -E -P std_map.cpp > preprocessed_49.cpp

After that I've compiled both files with g++-4.8 first and g++-4.9 second to
compare results. And it turned out that they are nearly the same for both
compilers depending on what file I compile. ftime-reports are in attachments.

I understand that it is not a bug per se, but compilation time for my project
that uses STL containers a lot jumped from 15 minutes to 40 minutes mark, and
it would be nice to reduce it back somehow.

[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2

[astellar at ro dot ru]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976

--- Comment #6 from Chernyshev Viacheslav <astellar at ro dot ru> ---
Created attachment 32697
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32697&action=edit
ftime-report, preprocessed by 4.8.2, compiled by 4.8.2

[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2

[astellar at ro dot ru]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976

--- Comment #8 from Chernyshev Viacheslav <astellar at ro dot ru> ---
Created attachment 32699
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32699&action=edit
ftime-report, preprocessed by 4.9.0, compiled by 4.8.2

[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2

[astellar at ro dot ru]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976

--- Comment #7 from Chernyshev Viacheslav <astellar at ro dot ru> ---
Created attachment 32698
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32698&action=edit
ftime-report, preprocessed by 4.8.2, compiled by 4.9.0

[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2

[astellar at ro dot ru]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976

--- Comment #9 from Chernyshev Viacheslav <astellar at ro dot ru> ---
Created attachment 32700
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32700&action=edit
ftime-report, preprocessed by 4.9.0, compiled by 4.9.0

[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976

--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Most of the libstdc++ changes are for C++11 allocator support, which is
required for conformance. Some changes I made in <bits/alloc_traits.h> might
have negatively affected compile time though.

[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2

[rene.koecher@wincor-nixdorf.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976

Rene Koecher <rene.koecher@wincor-nixdorf.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rene.koecher@wincor-nixdorf
                   |                            |.com

--- Comment #11 from Rene Koecher <rene.koecher@wincor-nixdorf.com> ---
Hi,
I want to chime in on this - is there anything new regarding the issue?
The current state marks it as UNCONFIRMED however there is some definite
performance loss even in the current 4.9.1 and 4.9.2 gcc releases.

My employer switched to gcc 4.9.1 recently and our codebase (mostly C++, heave
users of stl / boost) has almost doubled it's compile time.
We're up to 60min for a clean compile - and that is with ccache enabled.
Plain, no-ccache compiles are even worse.

Compiling with -ftime-report shows that g++ is spending significant ammounts of
time in the 'parsing' stage (mostly between 1.8 and 2.8sec/per file).

Currently we're using 4.9.1 on CentOS 5 (custom build) but I also confirmed the
same increase in compile time on a Gentoo and Debian system.

[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |trippels at gcc dot gnu.org

--- Comment #12 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
As Jonathan wrote, the standard library must conform to the C++ standard.

You simply cannot expect fast compile times out of the box when you make heavy
use of stl/boost.
(Although careful analysis might bring it down considerably. (e.g., bundling
most template instantiations into a single compilation unit))

For the attached testcase clang's libc++ is even 30% slower than gcc-4.9
libstdc++.

[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976

--- Comment #13 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I spent several hours trying to find the cause of the slowdown, without
success. Currently I am focused on fixing regressions and conformance errors. I
will come back to this when I can.

[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2

[rene.koecher@wincor-nixdorf.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976

--- Comment #14 from Rene Koecher <rene.koecher@wincor-nixdorf.com> ---
(In reply to Markus Trippelsdorf from comment #12)
> As Jonathan wrote, the standard library must conform to the C++ standard.
> 
> You simply cannot expect fast compile times out of the box when you make
> heavy use of stl/boost.
> (Although careful analysis might bring it down considerably. (e.g., bundling
> most template instantiations into a single compilation unit))
> 
> For the attached testcase clang's libc++ is even 30% slower than gcc-4.9
> libstdc++.

I agree on your point here, however shouldn't an unchanged codebase (and we're
not using C++11 features or -std=c++11 yet) at least keep the same performance?
It's understandable that standards compliance can counter performance but I
honestly wouldn't expect the compiler performance of older code / code not
using the new features to drop that drastically..

[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976

--- Comment #15 from Jonathan Wakely <redi at gcc dot gnu.org> ---
For the program in comment 5 most of the difference in compile-time is caused
by the allocator-aware container requirements (additional constructors which
need to be instantiated for every explicit instantiation in the program and
more complicated definitions for copy/move/swap). These changes are required
for C++11 conformance, and I don't see any obvious way to implement them
without affecting compile times.

There is also some increase in compile-time caused by extra 'noexcept'
specifications added to lots of functions, especially iterator member functions
and operators. Not all of those are required by the standard, but they are
important nonetheless.

[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2

[rene.koecher@wincor-nixdorf.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976

--- Comment #16 from Rene Koecher <rene.koecher@wincor-nixdorf.com> ---
Thank you Jonathan, that explains some things.
I get it there is also no easy way to disable certain standards features at
compile time?

[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976

--- Comment #17 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Rene Koecher from comment #14)
> I agree on your point here, however shouldn't an unchanged codebase (and
> we're not using C++11 features or -std=c++11 yet) at least keep the same
> performance?

No, because the standard library headers you include are not unchanged if you
upgrade the compiler.

> It's understandable that standards compliance can counter performance but I
> honestly wouldn't expect the compiler performance of older code / code not
> using the new features to drop that drastically..

Please provide a testcase demonstrating the problem with pre-C++11 code.

[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976

--- Comment #18 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #15)
> For the program in comment 5 most of the difference in compile-time is
> caused by the allocator-aware container requirements (additional
> constructors which need to be instantiated for every explicit instantiation
> in the program and more complicated definitions for copy/move/swap). These
> changes are required for C++11 conformance, and I don't see any obvious way
> to implement them without affecting compile times.

Just to confirm, the regression started with r204848 (~25% compile time
slowdown with -O0 on sandybridge).

[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2

[ott at fb dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976

Giuseppe Ottaviano <ott at fb dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ott at fb dot com

--- Comment #19 from Giuseppe Ottaviano <ott at fb dot com> ---
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.

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.

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.

[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2

[redi at gcc dot gnu.org]

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.

[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976

--- Comment #21 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #20)
> (In reply to Giuseppe Ottaviano from comment #19)
> > 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.

Oh, I looked at the wrong bit of r225244, it's using SFINAE in a
trailing-return-type that matters here, not the __detected_or_t_ changes.

[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2

[ott at fb dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976

--- Comment #22 from Giuseppe Ottaviano <ott at fb dot com> ---
>> 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.
> Oh, I looked at the wrong bit of r225244, it's using SFINAE in a
> trailing-return-type that matters here, not the __detected_or_t_
> changes.

Yes I referred to the trailing return type. Unfortunately it's not trivial to
test it with our code because alloc_traits.h is not anymore a drop-in
replacement. Maybe the test code included in this bug is enough? Is r225244
already included in a GCC release?

[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976

--- Comment #23 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Giuseppe Ottaviano from comment #22)
> Yes I referred to the trailing return type. Unfortunately it's not trivial
> to test it with our code because alloc_traits.h is not anymore a drop-in
> replacement. Maybe the test code included in this bug is enough? Is r225244
> already included in a GCC release?

No, only on trunk. It depends on the additions in r225242, so to use the new
alloc_traits.h you would only need the new code in
https://gcc.gnu.org/viewcvs/gcc/trunk/libstdc%2B%2B-v3/include/std/type_traits?r1=225242&r2=225241&pathrev=225242
(which could be added to the top of alloc_traits.h just in order to test, if
that's easier).

[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2

[ott at fb dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976

--- Comment #24 from Giuseppe Ottaviano <ott at fb dot com> ---
> No, only on trunk. It depends on the additions in r225242, so to use the new
> alloc_traits.h you would only need the new code in
> https://gcc.gnu.org/viewcvs/gcc/trunk/libstdc%2B%2B-v3/include/std/
> type_traits?r1=225242&r2=225241&pathrev=225242 (which could be added to the
> top of alloc_traits.h just in order to test, if that's easier).

Does __detected_or_t depend on some new language features? I copied all the
required metafunctions (including __void_t and __ptr_rebind), and I get this
error:

.../bits/alloc_traits.h: In substitution of 'template<class _Tp> using
__v_pointer = typename _Tp::void_pointer [with _Tp =
std::allocator<std::thread::_Impl<std::_Bind_simple<std::function<void()>()> >
>]':
.../bits/alloc_traits.h:57:29:   required from 'struct std::__detector<void*,
void, std::__allocator_traits_base::__v_pointer,
std::allocator<std::thread::_Impl<std::_Bind_simple<std::function<void()>()> >
> >'

[...]

.../bits/alloc_traits.h:103:53: error: no type named 'void_pointer' in 'class
std::allocator<std::thread::_Impl<std::_Bind_simple<std::function<void()>()> >
>'

Looks like it is ignoring the __detector negative case.

[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2

[ott at fb dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976

--- Comment #26 from Giuseppe Ottaviano <ott at fb dot com> ---
(In reply to Jonathan Wakely from comment #25)
> There was a G++ bug (now fixed) that made void_t not work, try this
> alternative version:
> 
> template< class... > struct __voider { using type = void; };
> template< class... _T0toN > using __void_t = typename
> __voider<_T0toN...>::type;

Thanks, I finally got it to work! I also had to hack back __alloctr_rebind
because hashtable.h depended on it.

I can confirm that, on my test files, the trailing return approach is not
slower than enable_if on return. 
Since std::allocator is pretty much the only used allocator, I also tried to
add a partial specialization allocator_traits<allocator<T>> so that no SFINAE
has to be performed, and there is a non-negligible speedup:

enable_if on return type: 100% (baseline)
_Require/enable_if on extra template argument: 225%
detected_or_t/trailing return type: 100%
partial specialization for allocator<>: 89%

This is all with GCC 4.9.2 with no optimization flags. GCC 5.2 gives similar
times.

Do you use partial specializations as performance optimizations (thus
equivalent to the general case) in libstdc++?

[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976

--- Comment #27 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Giuseppe Ottaviano from comment #26)
> Do you use partial specializations as performance optimizations (thus
> equivalent to the general case) in libstdc++?

No, but doing so for std::allocator_traits<std::allocator<T>> might make sense.

[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2

[rene.koecher@wincor-nixdorf.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976

--- Comment #28 from Rene Koecher <rene.koecher@wincor-nixdorf.com> ---
(In reply to Giuseppe Ottaviano from comment #26)

Giuseppe, is there an easy way you could provide me with your changes to
alloc_traits.h?

I'd really like to give it a shot against our codebase and see if there's any
speedup. I tried to follow along by taking the alloc_traits.h from 225242
adding the suggested diff to compensate for the missing bits in type_traits.

While this results in a working drop-in replacement I can not detect any
noticable changes in compile time.

[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2

[ott at fb dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976

--- Comment #29 from Giuseppe Ottaviano <ott at fb dot com> ---
(In reply to Rene Koecher from comment #28)
> (In reply to Giuseppe Ottaviano from comment #26)
> 
> Giuseppe, is there an easy way you could provide me with your changes to
> alloc_traits.h?
> 
> I'd really like to give it a shot against our codebase and see if there's
> any speedup. I tried to follow along by taking the alloc_traits.h from
> 225242 adding the suggested diff to compensate for the missing bits in
> type_traits.
> 
> While this results in a working drop-in replacement I can not detect any
> noticable changes in compile time.

Interesting, in a previous comment you say that you see a large jump in
"parsing" time, while in my case (and also in the attached reports) the largest
increases are in template instantiation. Maybe you have a different problem?

Anyway, of course I can share my changes (please ignore the weird formatting):
https://gist.github.com/ot/b094d58bf049cee3db99

If replacing alloc_traits.h does not work, try also allocator.h, it includes
the partial specialization that shortcuts SFINAE.

[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976

--- Comment #30 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.

Do you have a testcase showing this slowdown?

I tried a partial specialization and it doesn't make much difference to the
test file in comment 5, confirming that the Facebook issue is different from
the original bug report, which is caused by the constructor overloads that are
required by the standard.