C++拾趣——STL容器的插入、删除、遍历和查找操作性能对比（ubuntu g++）——删除
? ? ? ? 相關環(huán)境和說明在《C++拾趣——STL容器的插入、刪除、遍歷和查找操作性能對比（ubuntu g++）——插入》已給出。本文將分析從頭部、中間和尾部對各個容器進行刪除的性能。（轉載請指明出于breaksoftware的csdn博客）
刪除
頭部刪除
元素個數(shù)>15000
? ? ? ? vector容器性能最差。由于它和其他容器性能差距比較大，我們將其從圖中去除。
? ? ? ? 除了set表現(xiàn)不好之外，其他容器都差不多。其中表現(xiàn)最好的是list和forward_list。
元素個數(shù)<4096
? ? ? ? 由于vector持續(xù)的表現(xiàn)的最差，我就沒在上圖中將其列出。
? ? ? ? set在這個場景下表現(xiàn)也很差。deque在元素超過2500左右時，“迎頭趕上”，成為第三差的容器。
元素個數(shù)<1024
? ? ? ? 可以看到deque的性能在此時是最好的，明顯要優(yōu)于list和forward_list。
元素個數(shù)<256
? ? ? ? 對于小容器，deque、list和forward_list的表現(xiàn)最好。
對比結果：
? ? ? ? vector表現(xiàn)最差。
? ? ? ? 容器元素比較多時，list和forward_list性能最好。
? ? ? ? 元素少于2500左右時，deque的性能最好。
中間刪除
元素個數(shù)>15000
? ? ? ? vector的性能最差。
? ? ? ? 除了vector，表現(xiàn)最差的是map系列的三個容器：multimap、map和unordered_multimap。
? ? ? ? 表現(xiàn)最好的是list和forward_list。
? ? ? ? 由于vector表現(xiàn)的太差，之后中間刪除的圖例都不再列出它。
元素個數(shù)<4096
? ? ? ? deque在元素個數(shù)達到1800左右執(zhí)行了高耗時操作。在此之前它要優(yōu)于list。
元素個數(shù)<256
? ? ? ? 對于小容器，效率最好的依次是：forward_list、deque和list。
對比結果：
? ? ? ? vector性能最差。
? ? ? ? list和forward_list在各種容器大小時，表現(xiàn)都很好。
? ? ? ? deque在元素個數(shù)少于1800左右時，表現(xiàn)僅次于forward_list。
尾部刪除
元素個數(shù)>15000
? ? ? ? 之前各個場景下表現(xiàn)優(yōu)異的forward_list此時表現(xiàn)的極差。由于差異非常大，之后各個容器大小圖例中都將不包含它。
? ? ? ? vector表現(xiàn)最優(yōu)，其次是deque和list。非關聯(lián)容器的表現(xiàn)都由于關聯(lián)容器。
元素個數(shù)<256
? ? ? ? 大容器的表現(xiàn)在小容器上也有著相似的體現(xiàn)。
結果對比：
? ? ? ? vector的效率最優(yōu)。其次是deque和list。
? ? ? ? forward_list效率最差。
結論：
? ? ? ? vector在頭部和中間刪除時，表現(xiàn)極差；在尾部刪除時，表現(xiàn)優(yōu)異。
? ? ? ? forward_list在尾部刪除時，表現(xiàn)極差；頭部和中間刪除時，表現(xiàn)優(yōu)異。
? ? ? ? list在各個場景下表現(xiàn)均較為優(yōu)異。
? ? ? ? deque在元素少于2500左右時，效率比較優(yōu)秀。元素超過這個閾值后，頭部刪除效率較差，中間和尾部刪除仍然不錯。
? ? ? ??文中圖例可從以下地址獲取：https://github.com/f304646673/stl_perf/tree/master/linux
總結
以上是生活随笔為你收集整理的C++拾趣——STL容器的插入、删除、遍历和查找操作性能对比（ubuntu g++）——删除的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： C++拾趣——STL容器的插入、删除、遍
- 下一篇： C++拾趣——STL容器的插入、删除、遍