C++拾趣——STL容器的插入、删除、遍历和查找操作性能对比（ubuntu g++）——删除

        相关环境和说明在《C++拾趣——STL容器的插入、删除、遍历和查找操作性能对比（ubuntu g++）——插入》已给出。本文将分析从头部、中间和尾部对各个容器进行删除的性能。（转载请指明出于breaksoftware的csdn博客）

删除

头部删除

元素个数>15000

erase_begin_16384_highest

        vector容器性能最差。由于它和其他容器性能差距比较大，我们将其从图中去除。

erase_begin_16384

        除了set表现不好之外，其他容器都差不多。其中表现最好的是list和forward_list。

元素个数<4096

erase_begin_4096

        由于vector持续的表现的最差，我就没在上图中将其列出。

        set在这个场景下表现也很差。deque在元素超过2500左右时，“迎头赶上”，成为第三差的容器。

元素个数<1024

erase_begin_1024标题

        可以看到deque的性能在此时是最好的，明显要优于list和forward_list。

元素个数<256

erase_begin_256

        对于小容器，deque、list和forward_list的表现最好。

对比结果：

        vector表现最差。

        容器元素比较多时，list和forward_list性能最好。

        元素少于2500左右时，deque的性能最好。

中间删除

元素个数>15000

erase_mid_16256_highest

        vector的性能最差。

erase_mid_16256

        除了vector，表现最差的是map系列的三个容器：multimap、map和unordered_multimap。

        表现最好的是list和forward_list。

        由于vector表现的太差，之后中间删除的图例都不再列出它。

元素个数<4096

erase_mid_4096

        deque在元素个数达到1800左右执行了高耗时操作。在此之前它要优于list。

元素个数<256

erase_mid_256

        对于小容器，效率最好的依次是：forward_list、deque和list。

对比结果：

        vector性能最差。

        list和forward_list在各种容器大小时，表现都很好。

        deque在元素个数少于1800左右时，表现仅次于forward_list。

尾部删除

元素个数>15000

erase_end_16384_highest

        之前各个场景下表现优异的forward_list此时表现的极差。由于差异非常大，之后各个容器大小图例中都将不包含它。

erase_end_16384

        vector表现最优，其次是deque和list。非关联容器的表现都由于关联容器。

元素个数<256

erase_end_256

        大容器的表现在小容器上也有着相似的体现。

结果对比：

        vector的效率最优。其次是deque和list。

        forward_list效率最差。

结论：

        vector在头部和中间删除时，表现极差；在尾部删除时，表现优异。

        forward_list在尾部删除时，表现极差；头部和中间删除时，表现优异。

        list在各个场景下表现均较为优异。

        deque在元素少于2500左右时，效率比较优秀。元素超过这个阈值后，头部删除效率较差，中间和尾部删除仍然不错。

        文中图例可从以下地址获取：stl_perf/linux at master · f304646673/stl_perf · GitHub