对于普通编程语言的哈希表实现来说，有多大？
说我想创建一个播放游戏Shiritori的程序。在用户输入单词后，如果该单词存在，则程序需要查找字典。为了防止持续的平面文件读取，在程序中加载100,000多个单词到一个哈希表开始一个明智的解决方案？
答案 0 :(得分：5)
这种数据有专门的数据结构和算法。 例如，Patricia Trie或Radix Tree比字符串的哈希表空间效率更高，但当然，作为树，查找计算复杂度为O（log n）并且构建它是O（n log n）。由于你是从文件中删除它，但是你可以用这样的方式编写文件，你可以用O（n）加载它。
C＃中的Hashtable（Dictionary）以这样的方式实现它没有上限，除了它使用内部32位整数寻址（它肯定不能有超过2亿个项目）。
字典中有100000项不太多。 使用垃圾收集器的语言更有问题的可能是你将有100000个分配的字符串，这对你的GC有一些压力。 您只需运行它就可以获得有关实际应用程序内存占用的更多信息。
如果记忆是一个真正的问题，请寻找Patricia Trie和Radix Tree，非常适合存储单词词典。 但是你可以开始使用字典，看看你的应用程序有多少内存。
进行粗略计算，将字符串视为unicode，并考虑到英文中的平均单词是5.1字母（我在网上阅读）并考虑每个字符串加上32字节（对象和长度），您将得到最小值对于4200000字节的字符串，（100000 *（32 + 5 * 2））内存的内存量，这是一个非常小的数量。
答案 1 :(得分：0)
物理限制（RAM）和实现限制（Java哈希映射与C＃哈希映射与STL或Boost等）除外;我认为哈希映射“应该”的散列表大小的上限取决于散列算法。哈希映射的初衷是随着集合的大小增长而实现恒定的查找时间。如果你有一个很好的散列算法，那么你可以为大量的值生成一个唯一的密钥;但是如果你有一个糟糕的哈希算法，那么当你开始发生碰撞时（你的哈希算法中有两个独特的输入生成相同的值），你的查找时间会变成废话，你会进入trikery以避免它。
但那不应该是你想要的。我只是把它扔到那里为讨论添加另一点，我认为还没有解决。我想你应该看看@Salvatore Previti的回答。鉴于问题，你提到的解决方案似乎更合适。
答案 2 :(得分：-1)
“太大了”？这就像问“什么是最好吃的食物？”
散列表越大，占用的内存越多，但运行得越快。你必须决定你需要更多，空间或时间。