tr1::hashtable::extract1st

[Peter Doerfler <peter at ltilib dot pdoerfler dot com>]

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