对于大型NSDictionary，objectForKey是否缓慢？

Question

1. 假设我们有非常大的 NSDictionary ，当我们想要调用 objectForKey 方法时，它会在核心中进行大量操作来获取值吗？或者它会直接指向内存中的值吗？
2. 它在核心中如何运作？

Answer 1

Collections Programming Topics for Core Foundation的CFDictionary部分（如果您想了解更多，请查看）：

  

字典 - CFDictionary类型的对象 - 是基于散列的   用于访问其值的键是任意的，   程序定义的数据片段（或指向数据的指针）。虽然关键   它通常是一个字符串（或者，在Core Foundation中，一个CFString对象）   可以是任何可以适合指针大小的东西 - 一个整数，a   引用Core Foundation对象，甚至是指向数据的指针   结构（可能不太可能）。

这就是维基百科对哈希表的看法：

  

理想情况下，哈希函数应将每个可能的键映射到唯一   槽索引，但这种理想在实践中很难实现（除非   哈希键是固定的;即新的条目永远不会添加到表中   在它创建后）。相反，大多数哈希表设计都假定   哈希冲突 - 映射到相同哈希值的不同键 - 将   发生，必须以某种方式适应。在一个井尺寸的哈希   表，每次查找的平均成本（指令数）   独立于表中存储的元素数量。很多哈希   表格设计也允许任意插入和删除   键值对，按固定平均值（实际上是摊销的）成本计算   操作

因此，性能取决于散列的质量。如果它是好的，那么访问元素应该是O（1）操作（即不依赖于元素的数量）。

编辑：

事实上，在进一步阅读了Core Foundation的Collections Programming Topics后，apple会回答你的问题：

  

保证CFDictionary对象中值的访问时间   对于任何实现，最坏的是O（log N），但通常为O（1）   （恒定时间）。插入或删除操作通常在   恒定时间，但在最坏的情况下是O（N * log N）。它是   通过密钥访问值比直接访问它更快。   字典往往比使用数组的内存使用更多的内存   相同数量的值。

Answer 2

NSDictionary本质上是一个哈希表结构，因此查找的Big-O是O（1）。但是，为了避免重新分配（并实现O（1））复杂性，您应该使用dictionaryWithCapacity:创建一个相应于数据集大小的新字典。