说我有以下map
定义:
std::map<string,Storage>
其中键是Storage
类实例的字符串表示形式
我的问题是,即使它声明map::find 复杂性
是对数的,string
大小对性能有影响吗?
我有map
的原因是为了能够快速访问Storage
类实例。但是,如果Storage
类的字符串表示很长,该怎么办?是否存在最大字符串大小(如果超出)会导致map
的冗余使用?
我的直觉告诉我,如果 Storage
类的字符串表示非常长,那么使用operator==
比较类本身也会很昂贵。所以无论字符串有多长,我都可以使用map
答案 0 :(得分:3)
是的,地图必须执行小于比较的键。这是一个字典比较,是字符串大小的线性WRT。
这不会影响find
方法的时间复杂度,后者指的是所需的比较次数。它会影响常数因素。
您的申请中是否重要应根据经验确定。
答案 1 :(得分:3)
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
答案 2 :(得分:2)
&#34;复杂性&#34;以比较为单位定义地图查找。所以&#34;对数大小&#34;意味着它将执行O(log(size()))
次密钥比较。对于昂贵的密钥比较,这确实会影响实际性能。
答案 3 :(得分:1)
是的,比较两个字符串(具有长共享前缀)通常是O(n)复杂度。
如果字符串不共享长前缀,则可能需要更少的时间。
通常,较长的字符串需要较长的时间进行比较。
如果key是一个字符串,也许你应该考虑unordered_map(hash_table)。