ServerFrame::HashMap VS stl::unordered_map-性能探究之旅-51CTO.COM

[[203360]]

1. 引言

突然就对项目中的HashMap有了强烈的好奇心，这个HashMap的实现够高效吗，和 std::unordered_map 的效率比较性能如何? 他们的插入效率、查找效率、空间使用率对比起来是分别是什么样的?也没有找到相关的测评，于是就自己动手，测试了一下，并对一些影响性能的地方修改、验证自己的猜想，最终得到一个比较好的hashmap的实践。整个过程还是比较有意思的，现记录并分享出来。

1.1 好了别的不说了给我结论就好

好吧，大家都很忙，先给一下简要结论，时间紧迫的同学也可以直接跳到文尾查看结论小节.

ServerFrame::HashMap 的哈希算法算出来的哈希值散列度不够，key的长度越长，散列能力越差，性能越差。
因为冲突处理的缘故，本文所做的几个用例中，极端情况下 ServerFrame::HashMap 的表现比 stl::unordered_map 差100倍;
哈希算法散列程度足够的时候，ServerFrame::HashMap 的表现比 stl::unordered_map 好。前者的插入效率是后者的10倍，查找效率3倍;
存储同样的数据,HashMap 耗内存多于 unordered_map;

1.2 show me the code

本文用到的测试代码和测试结果全部在 git.oa.com中，有兴趣的同学可以下载查看。

仓库路径:http://git.code.oa.com/lawrencechi/hashmap-benchmark.git 
成文时仓库版本 tag:v2.0 
内存: 12G 
cpu 2核:   i7-6700 CPU 3.40GHz 
ServerFrame::HashMap: 编译时预设的容量是 8000万 
 
测试用例: 
lawrencechi@lawrencechi-VirtualBox /data/hashmap-benchmark/hashmap-benchmark/build ±master:zap: » ./bm_hashmap.O2 
Usage: bm_hashmap.O2 [-n count] -hijklmop 
   -h: hashmap-int 
   -i: hashmap-string(32 byte) 
   -j: unordered-map-int 
   -k: unordered-map-string 
   -l: hashmap(32 byte)) idx 
   -m: hash<string> idx 
   -o: hashmapplus(32 byte)) idx 
   -p: hashmapplus-string(32 byte))

2.int类型key

2.1用例结果

执行./bm_hashmap.O2 -n 700 -hj,获得数据，并绘制图表如下(画图数据经过省略，但关键信息还在,下同)

[图: 2.1插入耗时 ]

[ 图:2.1查找耗时 ]

总体来看，两个实现的效率都很高，稳定(斜率不变，意味着单位时间内插入条数没有变化)，插入8000万条数据最多只需要4.5s，在使用 ServerFrame::HashMap插入数据的时候，HashMap甚至能够达到 stl::unordered_map的10倍;当key不存在的时候，HashMap 查找速度也比 unordered_map 快4倍， key 存在的时候，容量少于5000万条时，HashMap 比 unordered_map 快，只有大于5000万时，两者查找的速度才相差不大。

这次测试看起来 HashMap 实现得非常完美，很好地解决了预设需求，插入效率高、查找效率高。虽然耗费的内存多，仅存8000万个int的 HashMap 需要 3.5G 的内存，但现代服务器内存充足，这个缺点似乎是可以忍受的。

除了内存之外，ServerFrame::HashMap 的实现就没有其他的缺点了吗? 很快，我就想到了他的 Hash 函数和冲突处理，决定从这里入手继续分析。

2.2 隐忧:hash算法

ServerFrame::HashMap 的 hash 算法实现是将 key 的 buffer(sizeof(key))，按照 int 字节累加，并将其结果和哈希表容量进行取余，简单粗暴，而且似乎也符合大道至简的理论。但是仔细想想,这个地方的实现违背了哈希算法的原则:均衡性。一个不够均衡性的算法会导致大量冲突，最终使得HashMap在反复的冲突处理中疲于奔命。

很简单，按照这个算法下面的这些数据算得到的哈希值都是一样的,而且这样的数据可以轻易地构造:

0xFFFFFFFF, 
0xFFFFFFFF 00000000 
0xFFFFFFFF 00000000 00000000 
0xFFFFFFFF 00000000 00000000 00000000

最为对比，我们都知道构造两个拥有同样MD5值的数据是何等的困难。

而且仔细分析一下可以知道 2.1 用例刚好绕过了这个算法的缺陷，取到的key都不会相互冲突! 这时候的测试结果恰恰是最优结果!

如果冲突了会怎么样,测试结果变成怎么样? 在好奇心驱使下，我马上进行 3.1 用例的测试。

3. buffer(32byte)类型

3.1用例结果

执行./bm_hashmap.O2 -n 700 -ik,获得数据，并绘制图表如下

[图： 3.1插入耗时 ]

从上图可以看到，对于buffer类型的key,性能表现差异很大.

从HashMap的图来看，越到后面斜率越大，说明到后面的时候，插入单位条数的耗时已经急剧增长。这是符合我们的设想的，此时程序在拼命进行冲突处理!

从图中还可以得到一个信息，插入7000万条数据，HashMap的耗时是接近2500秒,也就是41分钟!

至于unordered_map,上图已经分析不出什么东西来，和HashMap比起来，它的变化太缓慢了。我只能抽出来单独分析，图如下:

[ [图：3.1插入耗时-unordered_map ]

unordered_map 斜率几乎不变，可以知道每次插入的耗时是相同的,稳定，插入7000万条数据，耗时25s，HashMap差不多是他的100倍。

从上面的测试结果可知 HashMap 的效率的确是急剧下降，但是这个急剧下降是 Hash 算法引起的吗? 还是需要定量分析!

4. hash 算法比较

4.1 unordered_map

stl::unordered_map 是C++11引进的,老版本也有，只是没有提供接口出来供外部使用。

恰好手头上有 gcc 4.9.3 的代码，于是一探究竟

//代码片段 ================== 
    //file:/data/study/gcc/gcc.4.9.3/gcc-4.9.3/libstdc++-v3/libsupc++/hash_bytes.cc +73 
    size_t _Hash_bytes(const void* ptr, size_t len, size_t seed) 
    { 
        const size_t m = 0x5bd1e995; 
        size_t hash = seed ^ len; 
        const char* buf = static_cast<const char*>(ptr); 
 
        // Mix 4 bytes at a time into the hash. 
        while(len >= 4) 
        { 
            size_t k = unaligned_load(buf); 
            k *= m; 
            k ^= k >> 24; 
            k *= m; 
            hash *= m; 
            hash ^= k; 
            buf += 4; 
            len -= 4; 
        } 
 
        // Handle the last few bytes of the input array. 
        switch(len) 
        { 
            case 3: 
                hash ^= static_cast<unsigned char>(buf[2]) << 16; 
            case 2: 
                hash ^= static_cast<unsigned char>(buf[1]) << 8; 
            case 1: 
                hash ^= static_cast<unsigned char>(buf[0]); 
                hash *= m; 
        }; 
 
        // Do a few final mixes of the hash. 
        hash ^= hash >> 13; 
        hash *= m; 
        hash ^= hash >> 15; 
        return hash; 
    }

对于可以转换成 size_t 类型的key，hash提供了几个特化哈希函数，直接返回((size_t)key)，上面的哈希函数是buffer类型的哈希函数，传入起始地址，得到哈希值。这个hash算法用了几个魔数，各种位运算得到一个 int32 的值，好吧，此时我已经不知道怎么才能构造两个碰撞数据了。

最为对比，HashMap的hash函数如下:

template <typename KEY_TYPE, typename DATA_TYPE, int NODE_SIZE, typename CMP_FUNC, int HASH_SIZE> 
int CHashMap<KEY_TYPE, DATA_TYPE, NODE_SIZE, CMP_FUNC, HASH_SIZE>::HashKeyToIndex(const KEY_TYPE& rstKey, int& riIndex) const 
{ 
    size_t uiKeyLength = sizeof(rstKey); 
    unsigned int uiHashSum = 0; 
 
    //目前Hash算法实现比较简单只是将Key值的每个字节的值加起来并对SIZE取模 
    unsigned int i; 
    for( i = 0; i < uiKeyLength / sizeof(unsigned int); ++i) 
    { 
        unsigned int uiTmp = 0; 
        memcpy(&uiTmp, ((char*)(&rstKey))+sizeof(uiTmp)*i, sizeof(uiTmp)); 
        uiHashSum += uiTmp; 
    } 
 
    if(uiKeyLength % sizeof(unsigned int) > 0) 
    { 
        unsigned char* pByte = (unsigned char*)&rstKey; 
        pByte += (uiKeyLength - (uiKeyLength % sizeof(unsigned int))); 
        unsigned int uiTemp = 0; 
        memcpy((void *)&uiTemp, (const void *)pByte, uiKeyLength%sizeof(unsigned int)); 
        uiHashSum += uiTemp; 
    } 
 
    uiHashSum = (uiHashSum & ((unsigned int)0x7fffffff)); 
    riIndex = (int)(uiHashSum % HASH_SIZE); 
    return 0; 
}