C++拾趣——STL容器的插入删除遍历和查找操作性能对比（ubuntu g++）——删除
Posted breaksoftware
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了C++拾趣——STL容器的插入删除遍历和查找操作性能对比（ubuntu g++）——删除相关的知识，希望对你有一定的参考价值。
相关环境和说明在《C++拾趣——STL容器的插入、删除、遍历和查找操作性能对比（ubuntu g++）——插入》已给出。本文将分析从头部、中间和尾部对各个容器进行删除的性能。（转载请指明出于breaksoftware的csdn博客）
删除
头部删除
元素个数>15000
vector容器性能最差。由于它和其他容器性能差距比较大，我们将其从图中去除。
除了set表现不好之外，其他容器都差不多。其中表现最好的是list和forward_list。
元素个数<4096
由于vector持续的表现的最差，我就没在上图中将其列出。
set在这个场景下表现也很差。deque在元素超过2500左右时，“迎头赶上”，成为第三差的容器。
元素个数<1024
可以看到deque的性能在此时是最好的，明显要优于list和forward_list。
元素个数<256
对于小容器，deque、list和forward_list的表现最好。
对比结果：
vector表现最差。
容器元素比较多时，list和forward_list性能最好。
元素少于2500左右时，deque的性能最好。
中间删除
元素个数>15000
vector的性能最差。
除了vector，表现最差的是map系列的三个容器：multimap、map和unordered_multimap。
表现最好的是list和forward_list。
由于vector表现的太差，之后中间删除的图例都不再列出它。
元素个数<4096
deque在元素个数达到1800左右执行了高耗时操作。在此之前它要优于list。
元素个数<256
对于小容器，效率最好的依次是：forward_list、deque和list。
对比结果：
vector性能最差。
list和forward_list在各种容器大小时，表现都很好。
deque在元素个数少于1800左右时，表现仅次于forward_list。
尾部删除
元素个数>15000
之前各个场景下表现优异的forward_list此时表现的极差。由于差异非常大，之后各个容器大小图例中都将不包含它。
vector表现最优，其次是deque和list。非关联容器的表现都由于关联容器。
元素个数<256
大容器的表现在小容器上也有着相似的体现。
结果对比：
vector的效率最优。其次是deque和list。
forward_list效率最差。
结论：
vector在头部和中间删除时，表现极差；在尾部删除时，表现优异。
forward_list在尾部删除时，表现极差；头部和中间删除时，表现优异。
list在各个场景下表现均较为优异。
deque在元素少于2500左右时，效率比较优秀。元素超过这个阈值后，头部删除效率较差，中间和尾部删除仍然不错。
文中图例可从以下地址获取：https://github.com/f304646673/stl_perf/tree/master/linux
以上是关于C++拾趣——STL容器的插入删除遍历和查找操作性能对比（ubuntu g++）——删除的主要内容，如果未能解决你的问题，请参考以下文章
C++拾趣——STL容器的插入删除遍历和查找操作性能对比（Windows VirtualStudio）——删除
C++拾趣——STL容器的插入删除遍历和查找操作性能对比（ubuntu g++）——删除
C++拾趣——STL容器的插入删除遍历和查找操作性能对比（Windows VirtualStudio）——插入