![](/img/trans.png)
[英]std::unordered_map: Asymptotic {search,insert,remove} performance in the size of the key, and by data type
[英]Does std::map::find performance depend on the key size?
說我有以下map
定義:
std::map<string,Storage>
其中鍵是Storage
類實例的字符串表示形式。
我的問題是,即使它聲明map :: find 復雜度的大小是對數的 , string
大小是否對性能有任何影響?
我有這個map
的原因是為了能夠快速訪問Storage
類實例。 但是,如果Storage
類的字符串表示很長,該怎么辦? 是否存在最大字符串大小(如果超出)會使map
冗余使用?
我的直覺告訴我,如果Storage
類的字符串表示很長,那么使用operator==
比較類本身也會很昂貴。 所以無論字符串有多長,我都更善於使用map
是的,地圖必須執行小於比較的鍵。 這是一個字典比較,是字符串大小的線性WRT。
這不會影響find
方法的時間復雜度, find
方法指的是所需的比較次數。 它會影響常數因素。
在您的申請中是否重要應該根據經驗確定。
std::map
使用密鑰類型的詞典排序。 這意味着地圖上搜索操作的性能取決於地圖中鍵的共享前綴和您要查找的鍵。 如果您有許多密鑰共享一個非常長的前綴,並且您搜索具有該前綴的密鑰,性能將會下降。
例如,這很昂貴:
aaaaaa <millions of a's> aaaa
aaaaaa <millions of a's> aaab
aaaaaa <millions of a's> aaac
這很便宜:
aaaaaa <millions of a's> aaaa
baaaaa <millions of a's> aaaa
caaaaa <millions of a's> aaaa
地圖查找的“復雜性”以比較為單位定義。 所以“對數大小”意味着它將執行O(log(size()))
鍵比較。 對於昂貴的密鑰比較,這確實會影響實際性能。
是的,比較兩個字符串(具有長共享前綴)通常是O(n)復雜度。
如果字符串不共享長前綴,則可能需要更少的時間。
通常,較長的字符串需要較長時間進行比較。
如果key是一個字符串,也許你應該考慮unordered_map(hash_table)。
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.