[Bug c++/54710] moderately large tuple, with many gets, increases compile time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54710 --- Comment #12 from Richard Biener --- (In reply to Eric Gallager from comment #11) > Created attachment 41894 [details] > result of compiling with -ftime-report -ftime-report-details -fstats > > (In reply to Larry Evans from comment #10) > > Created attachment 28294 [details] > > with optimized clang, still with optimized gcc, both with -O1 > > > > Remade clang with make ENABLE_OPTIMIZED=1. Clang times improved a lot. > > > > Now, the degradation of relative performance of gcc w.r.t. clang > > is more dramatic. > > > > Still, gcc does better at low LAST_LESS, but reaches break even > > at lower LAST_LESS (about 8). > > Confirmed: > > $ /usr/local/bin/gcc -c -O1 -time tuple.benchmark.mini.horiz.cpp > # cc1plus 4.62 0.25 > # as 0.02 0.01 > $ > > I guess 4 and a half seconds is kinda long. Attaching a more detailed time > report as a separate file. Time is spent in the C++ parser and the GIMPLE/tree verifiers. Your cc1plus is built with --enable-checking=yes ...
[Bug c++/54710] moderately large tuple, with many gets, increases compile time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54710 Eric Gallager changed: What|Removed |Added Keywords||compile-time-hog Status|WAITING |NEW Last reconfirmed|2012-09-25 00:00:00 |2017-8-2
[Bug c++/54710] moderately large tuple, with many gets, increases compile time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54710 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #11 from Eric Gallager --- Created attachment 41894 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41894=edit result of compiling with -ftime-report -ftime-report-details -fstats (In reply to Larry Evans from comment #10) > Created attachment 28294 [details] > with optimized clang, still with optimized gcc, both with -O1 > > Remade clang with make ENABLE_OPTIMIZED=1. Clang times improved a lot. > > Now, the degradation of relative performance of gcc w.r.t. clang > is more dramatic. > > Still, gcc does better at low LAST_LESS, but reaches break even > at lower LAST_LESS (about 8). Confirmed: $ /usr/local/bin/gcc -c -O1 -time tuple.benchmark.mini.horiz.cpp # cc1plus 4.62 0.25 # as 0.02 0.01 $ I guess 4 and a half seconds is kinda long. Attaching a more detailed time report as a separate file.
