public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "plasmahh at gmx dot net" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/54075] [4.7.1] unordered_map 3x slower than 4.6.2
Date: Tue, 24 Jul 2012 10:42:00 -0000	[thread overview]
Message-ID: <bug-54075-4-fxlmTg2nTh@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-54075-4@http.gcc.gnu.org/bugzilla/>

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

Dennis Lubert <plasmahh at gmx dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |plasmahh at gmx dot net

--- Comment #8 from Dennis Lubert <plasmahh at gmx dot net> 2012-07-24 10:41:54 UTC ---
I just stumbled over this bug while searching for something related to the max
load factor (it seems that since 4.7 the hashtable also shrinks when you set
the load factor higher, which is at least for me unfortunate).

I did just change the testcase to count the number of rehashes (by checking
bucket count before and after insert) and found:

gcc4.6 without reserve: 21
gcc4.6 with reserve: 1

gcc4.7 without reserve: 155
gcc4.7 with reserve: 160

Then in callgrind I had a look and most time seems to be spend in rehashing. So
I would assume that when the 4.7 version gets the number of rehashing down to
where it was, then we also get the speed down to where it was.

I would say that the reserve behaviour though is definetly broken, as it even
increases the amount of rehashings. I personally would just not have the
hashtable ever shrink on insert and/or load factor setting, just only ever on
explicit rehash() calls...


  parent reply	other threads:[~2012-07-24 10:42 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-23 23:07 [Bug libstdc++/54075] New: " likan_999.student at sina dot com
2012-07-23 23:08 ` [Bug libstdc++/54075] " likan_999.student at sina dot com
2012-07-23 23:09 ` likan_999.student at sina dot com
2012-07-23 23:12 ` paolo.carlini at oracle dot com
2012-07-23 23:23 ` paolo.carlini at oracle dot com
2012-07-24  0:17 ` likan_999.student at sina dot com
2012-07-24  0:29 ` paolo.carlini at oracle dot com
2012-07-24  0:43 ` likan_999.student at sina dot com
2012-07-24 10:42 ` plasmahh at gmx dot net [this message]
2012-07-24 20:15 ` fdumont at gcc dot gnu.org
2012-07-24 20:19 ` fdumont at gcc dot gnu.org
2012-07-25  9:56 ` paolo.carlini at oracle dot com
2012-07-25 19:33 ` fdumont at gcc dot gnu.org
2012-07-26 12:30 ` plasmahh at gmx dot net
2012-07-26 12:32 ` fdumont at gcc dot gnu.org
2012-07-26 17:36 ` paolo.carlini at oracle dot com
2012-07-26 22:10 ` likan_999.student at sina dot com
2012-07-26 22:50 ` chip at pobox dot com
2012-07-26 22:55 ` paolo.carlini at oracle dot com
2012-07-26 23:39 ` [Bug libstdc++/54075] [4.7.1] unordered_map insert " chip at pobox dot com
2012-07-27  0:33 ` redi at gcc dot gnu.org
2012-07-27  1:00 ` chip at pobox dot com
2012-07-27  7:58 ` fdumont at gcc dot gnu.org
2012-07-27 19:21 ` plasmahh at gmx dot net
2012-07-29 16:44 ` fdumont at gcc dot gnu.org
2012-07-29 17:06 ` fdumont at gcc dot gnu.org
2012-09-26 23:11 ` paolo.carlini at oracle dot com
2012-10-22 20:50 ` cracauer at cons dot org
2012-10-22 21:05 ` paolo.carlini at oracle dot com
2012-10-22 22:04 ` cracauer at cons dot org
2012-10-22 22:47 ` paolo.carlini at oracle dot com
2012-10-24 19:28 ` fdumont at gcc dot gnu.org
2012-10-25 17:48 ` cracauer at cons dot org
2012-10-26 14:35 ` paolo.carlini at oracle dot com
2012-11-03 15:28 ` fdumont at gcc dot gnu.org
2012-11-04  4:55 ` foom at fuhm dot net
2012-11-05 12:55 ` [Bug libstdc++/54075] [4.7.1] unordered_map insert still " paolo.carlini at oracle dot com
2012-11-05 22:12 ` tlawrence85 at gmail dot com
2012-11-06  0:59 ` paolo.carlini at oracle dot com
2012-11-06 21:23 ` fdumont at gcc dot gnu.org
2012-11-06 21:34 ` paolo.carlini at oracle dot com
2012-11-07 22:03 ` frs.dumont at gmail dot com
2012-11-08  0:59 ` jwakely.gcc at gmail dot com
2012-11-08  1:56 ` paolo.carlini at oracle dot com
2012-11-08  2:26 ` paolo.carlini at oracle dot com
2012-11-08 20:06 ` fdumont at gcc dot gnu.org
2012-11-08 20:16 ` fdumont at gcc dot gnu.org
2012-11-08 20:21 ` frs.dumont at gmail dot com
2012-11-08 21:19 ` frs.dumont at gmail dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-54075-4-fxlmTg2nTh@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).