https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80826
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80826
--- Comment #8 from Jonathan Wakely ---
Even the unchanged code is almost acceptable with -fno-var-tracking-assignments
TOTAL : 357.361.11 359.181206964 kB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80826
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80826
--- Comment #6 from Jonathan Wakely ---
Using -fno-var-tracking-assignments helps too.
Inserting the right type:
TOTAL: 291.541.14 293.251237034 kB
Range-insert from an array of the right type:
TOTAL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80826
--- Comment #5 from Jonathan Wakely ---
FWIW using -O1 -g -ftime-report on the original code with GCC 5.4.1 gives:
TOTAL :1387.175.14 1462.362427702 kB
And also prints the -fvar-tracking-assignments note.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80826
--- Comment #4 from Jonathan Wakely ---
I don't know why it's so slow, or if it's possible to change the libstdc++ code
to help the c++98 case (I doubt it).
But it helps a lot if you insert the correct type:
mMap.insert (std::pair("1",
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80826
--- Comment #3 from Richard Biener ---
For GCC 7 most time is spent in inlining. I suspect C++14 helps with constexpr
evaluation doing some of the stuff in the frontend.
integration : 21.73 (39%) usr 0.33 (23%) sys 22.02 (39%)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80826
Richard Biener changed:
What|Removed |Added
Target|Red Hat 7 Linux x86 64bit |
Status|UNCONFIRMED
