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容器的插入、删除、遍
- 下一篇： C++拾趣——STL容器的插入、删除、遍