首先，“常数 O(m) 查找”是没有意义的。在 Trie 中查找时间是 O(m)：它取决于您要查找的字符串的长度。
构建良好的哈希表（即良好的哈希函数和合理的负载因子）具有 O(1) 的查找时间。
在假定构造胜任的情况下，在哈希表中查找一个字符串将比在 Trie 中查找快得多。
Trie 和哈希表用于不同的目的。如果您只想查找单词，则哈希表会更快。如果您想查找常见前缀、有序检索或执行类似的操作，则需要 Trie。
哈希表可以非常快地查找单个字符串。就像一匹赛马一样迅速。这就是它所能够做的
全部。而另一方面，Trie 是一匹勤劳的工作马，可以做很多事情。它的查找速度永远不会像哈希表那么快，但它可以做许多哈希表无法做的事情。
例如，使用字典查找以“pre”开头的所有单词将需要O(n)的时间，因为您必须搜索所有单词。使用 Trie 只需三次探测就可以找到包含所有这些单词的子树，然后您只需遍历该子树。当然，最坏情况是O(n)，但这只有在您的 Trie 中的所有单词都以“pre”开头时才会发生。
虽然确实，如果整个 Trie 都在内存中，则访问磁盘将比较慢，但说基于磁盘的 Trie 不提供任何优势与备选项是错误的。如果数据无法放入内存中，则无论您使用什么数据结构，都需要一些外部（即非内存）存储。当数据在磁盘上时，访问速度变慢并不会从根本上改变 Trie 与哈希表的优缺点。例如，基于磁盘的 Trie 在查找具有特定前缀的所有单词时仍将比基于磁盘的哈希表更快。
哈希表的开销通常是其包含的单词数量的恒定倍数。也就是说，除了存储字符串所需的内存外，还有每个字符串的开销来存储哈希码和字符串之间的映射关系。
Trie 的内存要稍微复杂一些。在最坏情况下，每个字符都有一个节点。所有这些小节点分配开始累加。想象一下包含 200,000 个单词且平均单词长度为五个字符的字典。那就是一百万个节点的开销。
幸运的是，有一些方法可以大大压缩 Trie 而不会失去太多或任何性能。生成的数据结构比朴素构建的 Trie 更小，更适合缓存。
