tr1::hashtable::extract1st

Peter Doerfler peter@ltilib.pdoerfler.com
Fri May 12 14:43:00 GMT 2006


Hi.

I'm experimenting a bit with unordered_map and while comparing it to 
hash_map, I found it to be factor 2 slower for one use case: Key is a 
vector class, which wraps a C array of ints, and only 4 keys in the map 
but loads of look-ups.
It turned out that the vector's copy ctor was responsible for the 
difference. It is being called since 
tr1::Internal::extract1st::operator() (in hashtable) returns by value 
and not by const ref as std::_Select1st. Changing the return type of 
extract1st::operator() gave me equal performance.

===================================================================
--- hashtable   (revision 113691)
+++ hashtable   (working copy)
@@ -412,7 +412,7 @@
    template<typename Pair>
      struct extract1st
      {
-      typename Pair::first_type
+      const typename Pair::first_type&
        operator()(const Pair& p) const
        { return p.first; }
      };

I can't see a reason not to change this (didn't dig into the proposal, 
though).
If this can be changed the same probably applies to Internal::identity.

Tests done on x86, compiled with -O3 -march=i586, gcc trunk rev 113691.

Best regards,
Peter


PS: Thanks Paolo for the quick (and much enhanced) commit for the 
hashtable iterators problem



More information about the Libstdc++ mailing list