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