【问题标题】:Why use a hashmap?为什么要使用哈希图?
【发布时间】:2011-04-25 05:18:33
【问题描述】:

有人告诉我哈希图相当慢。所以我只是想知道是使用 hashmap 还是 switch case 逻辑。

我的要求是这样的。我有一组 CountryNames 和 CountryCodes。我的 ListView 显示国家/地区的名称。当一个国家名称项目被点击时,我必须 Toast the CountryCode。

在这种情况下,我是否应该维护 CountryNames 和 Codes 的 HashMap 并访问它以获取相应的 Code?:

myMap.put("US", 355);
myMap.put("UK", 459);
//etc

还是像这样写一个switch case比较好

switch (vCountryNamePos):
{
case 0:   //US
vCountryCode = 355;
break;
case 1:   //UK
vCountryCode = 459;
break;

//etc
}

哪个更快?如果不是 Hashmap,那么 Map 会在哪些实际场景中使用?

-奇奇

【问题讨论】:

  • 这个问题似乎不是 android 特有的。

标签: java android listview hashmap switch-statement


【解决方案1】:

对于两个值,切换会更快。哈希图将始终至少检查您的密钥是否相等,因此它无法击败一两个 .equals() 测试。
对于许多值,散列会更快。交换机必须测试每个值,直到找到正确的值。

对于少量值(最多 10 个左右),最好使用开关。它会更轻、更快。
对于大量值(超过 50 个),首选哈希。哈希不必检查所有值,因此当值的数量增加时它会比开关更快。 对于 10~50 的值,我建议你做你认为更具可读性的东西,因为性能会相似。

现在,如果您正在研究编译时已知的静态字符串的极端性能,您可以考虑使用 gnuperf 等代码生成工具。
如果您在编译时不知道您的字符串,但您知道它们的长度会相当短且相当统一,或者具有通用前缀,那么使用 Trie 数据结构可能会最快。
如果您想在大量非常异构的字符串或可能不是字符串的对象上保持性能,那么 HashMap 是要走的路。当对象数量非常多(数十亿或更多)时,它几乎是无与伦比的。

【讨论】:

  • 请注意,在这种特殊情况下,您可能希望使用 Android 的 SparseArray 之类的东西来避免自动装箱/拆箱。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2021-06-03
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2015-04-28
  • 2010-11-03
相关资源
最近更新 更多