链接列表或哈希表？

Question

我有一个大约5000个条目的链表（同时插入“NOT”），我正在遍历列表，偶尔寻找一个特定的条目（虽然这不常见），我应该将哈希表视为一个这种情况的更佳选择，取代链表（双链和线性）？在Linux中使用C语言。

Answer 1

是否使用哈希表更优化取决于用例，您没有详细描述。但更重要的是，确保性能的瓶颈在于代码的这一部分。如果此代码仅在一段时间内调用一次而不是在关键路径中调用，则不必费心去更改代码。

Answer 2

如果您没有通过分析器发现代码是应用程序的缓慢部分，那么您不应该对它做任何事情。

如果它很慢，但代码经过测试，有效，并且很清晰，还有其他较慢的区域，你可以加快速度，先做这些。

如果它有问题，那么无论如何都需要修复它，去哈希表，因为它会比列表更快。这假设遍历数据的顺序无关紧要，如果您关心插入顺序是什么，那么坚持使用列表（您可以使用哈希表执行操作并保留顺序，但这会使代码变得非常棘手）。

鉴于您只需要偶尔搜索列表，这可能是您代码中一个重要瓶颈的可能性很小。

要查看的另一个数据结构是“跳过列表”，它基本上允许您跳过列表的大部分内容。这需要对列表进行排序，这取决于您正在执行的操作，可能会使代码整体变慢。

Answer 3

您是否通过查找测量并发现了性能损失？ hash_map或hash table应该是好的。

Answer 4

如果您需要按顺序遍历列表（不是搜索元素的一部分，而是说显示它们），那么链接列表是一个不错的选择。如果你只是存储它们以便你可以查找元素，那么哈希表将大大优于链表（除了最糟糕的哈希函数之外）。

如果您的应用程序要求同时执行这两种类型的操作，您可以考虑保留这两种操作，并使用适合特定任务的任何一种操作。内存开销很小，因为你只需要在内存中保留每个元素的一个副本，并让数据结构存储指向这些对象的指针。

与您采取的任何优化步骤一样，请确保在进行任何更改之前测量代码以找到真正的瓶颈。

Answer 5

如果你关心表现，你肯定应该。如果你正在迭代这个东西以找到任何规律性的某个元素，那么使用哈希表是值得的。但是，如果这是一种罕见的情况，并且列表的普通使用不是搜索，那么就没有理由担心它。

Answer 6

如果你只遍历集合，我看不到使用hashmap的任何好处。

Answer 7

我建议几乎在所有情况下反对哈希。

有两个原因;首先，哈希的大小是固定的。

第二，更重要的是;哈希算法。你怎么知道你做得对吗？它将如何使用真实数据而不是测试数据？

我建议使用平衡的b树。总是O（log n），对哈希算法没有不确定性，没有大小限制。