C + + STL map with red black tree implementation, search efficiency is O (LgN), why not like Python with a hash table to obtain the constant-level search efficiency?

Reply content:

Standard provisions in C + + STL:
* Map, ordered
* Unordered_map, unordered, this is to use a hash table to talk about the difference between hashmap and map, we know that HashMap is the average O (1), map is the average O (LnN), in practice is not hashmap better than the map? Here are a few factors to consider:

1. HashMap's memory efficiency is worse than map, which is obvious.
2. The search efficiency of map is very high in practice, such as how many comparisons are needed to find an element in 1M data? 20 times.
3. Map lookup efficiency is more stable than hashmap.
4. HashMap find time to calculate the hash, the worst time complexity is O (m) (m is the length of the key string), if your key is very very very very very very ... Long, comparison-based maps are usually compared using only the first few characters, and HashMap to O (M) to calculate the hash
5. Memory layout affects memory locality and performance impacts

A red-black tree means that for a key value it is an ordered store, which is handy when you need to find a range of key values. Time is still (LOGN).
Conversely, if you use a hash, you will have to traverse the entire value space, when (N). Most of the time, we do not need this "order", even in some special cases, we need the "orderly", is not "dynamic and orderly", there is a 0 of the cost of supporting the sort of gold_hash_map , GM, and Std::unordered_xxx and Google's spasre_xxx, dense_xxx faster and less memory standards the elements of map must be ordered, and efficiency can be considered when standards are met. The hash list does not guarantee that the element is ordered, so it cannot be used. Map, the speed is stable, and orderly;
Hashtable, sometimes faster than map, and sometimes slower than the map is not several times. Picky eaters (Unable to find a good hash), gullible (intentional data collisions).

In non-real-time situations, you can choose Hashtable, because statistically it is faster than map;
In real-time situations, you can only choose map, because he will not be as slow as Hashtable sometimes.

1. Houtie in the 5th chapter of the STL source analysis, the author mentions that hash table (hash list) and its derivative containers are very important. They were not included in the C + + standard because the proposal was too late. The next generation of C + + standard libraries are likely to be incorporated into them.
2. Hash table (hash list) is provided in SGI STL, and Hash_set (hash set), Hash_map (hash map), Hash_multiset (hash multi-key collection) are completed with this hash table as the underlying mechanism, hash_ Multimap (hash multi-key mapping table). Unorder_map is also introduced in the new C + + STL.
3. On the time complexity (lookup) and spatial complexity of map and unordered_map

Take a look at the answer to stack overflow C + +-is there any advantage of the using map over unordered_map in case of trivial keys?
The main answer is:
1, map is orderly, unordered_map is disorderly
2. The search speed between the two is different (log (n) and N)
3, because the hash to control the load rate between 0-1, so unordered_map consumes more space.
Specific time and space consumption:
Hash is an implementation of ordinary dictionary abstract data type, and RBT is an implementation of ordered dictionary abstract data type. Ordinary dictionary only supports search, insert, delete,ordered dictionary In addition to the three operations, it also supports the operation of some navigation classes, such as the closest key to a given key, the maximum key, and the minimum key.
The implementation of the two kinds of dictionary has the applicable scene. It may be that when the C + + standard library was set, hash table was not popular. Now 11 of the standard libraries have added hash-based unordered_set and unordered_map.
In addition, it is not enough to see the complexity of the algorithm in the light. The log time may be a very small factor, and the constant time may be a large factor. try these functions, and next time you don't ask for a sequence, you're going to want to use a hash instead of a red-black tree. Try these functions, and next time you don't ask for a sequence, you're going to want to use a hash instead of a red-black tree.

