在 C# 中优化列表性能答案

【问题标题】：Optimizing list performance in C#在 C# 中优化列表性能
【发布时间】：2015-08-24 18:38:08
【问题描述】：

我正在开发一个项目（在 .NET 3.5 中），它读取 2 个文件，然后比较它们并找到丢失的对象。

基于这些数据，我需要进一步解析并定位对象位置。我将尝试进一步解释：

我有 2 个列表： 1 列表是服务器上所有文件的非常长的列表，以及它们在服务器或其他服务器上的物理地址，该文件的长度超过 10 亿行，并且还在不断增长（我知道有点荒谬）。目前文件大小约为 160MB。另一个列表是显示服务器上丢失文件的报告列表。与列表 1 相比，此列表很小，通常小于 1MB。

我必须将列表 2 与列表 1 相交并确定丢失对象的位置。列表中的项目如下所示（不幸的是，它是空格分隔的，而不是 CSV 文档）： filename.extension rev rev# source server:harddriveLocation\|filenameOnServer.extension origin

使用流，我将两个文件读入单独的字符串列表。然后我使用一个正则表达式并将列表 2 中的项目解析为包含 filename.extension、rev 和 rev# 的第三个列表。所有这一切都非常有效，它的表现让我很生气。

我希望有一种更有效的方法来做我正在做的事情。

foreach (String item in slMissingObjectReport)
{
    if (item.Contains(".ext1") || item.Contains(".ext2") || item.Contains(".ext3"))
    {
        if (!item.Contains("|"))
        {                                     
            slMissingObjects.Add(item + "," + slMissingObjectReport[i + 1] + "," + slMissingObjectReport[i + 2]); //object, rev, version
        }
    }

    i++;
}

int j = 1; //debug only

foreach (String item in slMissingObjects)
{
    IEnumerable<String> found = Enumerable.Empty<String>();
    Stopwatch matchTime = new Stopwatch(); //used for debugging
    matchTime.Start(); //start the stop watch

    foreach (String items in slAllObjects.Where(s => s.Contains(item.Remove(item.IndexOf(',')))))
    {
        slFoundInAllObjects.Add(item);
    }

matchTime.Stop();

tsStatus.Text = "Missing Object Count: " + slMissingObjects.Count + " | " + "All Objects count: " + slAllObjects.Count + " | Time elapsed: " + (taskTime.ElapsedMilliseconds) * 0.001 + "s | Items left: " + (slMissingObjects.Count - j).ToString();

j++;
}

taskTime.Stop();
lstStatus.Items.Add(("Time to complete all tasks: " + (taskTime.ElapsedMilliseconds) * 0.001) + "s");

这可行，但由于目前我的丢失对象列表中有 1300 个丢失项目，因此平均需要 8 到 12 分钟才能完成。耗时最长的部分是

foreach (String items in slAllObjects.Where(s => s.Contains(item.Remove(item.IndexOf(',')))))
{
    slFoundInAllObjects.Add(item);
}

我只需要指出正确的方向，或许还需要帮助我了解如何改进我正在编写的代码。 LINQ 看起来并不是杀手，它把它添加到一个似乎会扼杀性能的列表中。

【问题讨论】：

为什么不使用数据库？
列表插入是 O(n)，因此您永远不会对使用列表作为数据结构的插入进行顶级优化。堆栈或哈希表呢？此外，您是否对其进行了分析以确保您发现了代码的慢速部分？
如果是预分配的，列表插入可以是 O(1)，你可以预分配吗？至少给出一个合理的期望？
不要使用列表。使用 HashSet。
slFoundInAllObjects.AddRange(slObjects.Where.....);为什么不使用 AddRange ？试试这个，看看。但是，问题也可能出在其他地方

标签： c# performance linq list hashset

【解决方案1】：

您可以进行的一项改进是使用AddRange 而不是Add。 AddRange 将允许内部列表预分配添加所需的内存，而不是在您的 foreach 循环过程中多次分配。

IEnumerable<string> items = slAllObjects.Where(s => s.Contains(item.Remove(item.IndexOf(','));
slFoundInAllObjects.AddRange(items);

其次，您应该避免在您的 Where lambda 中使用 item.Remove(item.IndexOf(',')，因为这会导致它对列表中的每个项目执行一次。该值是静态的，您可以提前执行一次。

var itemWithoutComma = item.Remove(item.IndexOf(','));
IEnumerable<string> items = slAllObjects.Where(s => s.Contains(itemWithoutComma));
slFoundInAllObjects.AddRange(items);

【讨论】：

我认为选项 1 行不通； slAllObjects.Where(s => s.Contains(item.Remove(item.IndexOf(',')); 将返回一个 IEnumerable.
是的，这是我的语法错误。我会修复的。不过，AddRange 的重点是您一次添加整个集合，因此 IEnumerable 正是您想要的。
它仍然相当慢。如果没有 addrange（或添加），它的速度非常快。我确实在我的 OP 中定义了一个 IEnumerable 。我在秒表之外测量时间的方式是在它自己的线程中运行任务，并计算项目通过的速度有多慢。平均而言，它似乎是每秒大约 1 个项目。当你有 1300 个项目时，它相当慢。我将转换为哈希集，看看结果如何。感谢您的帮助和快速响应。

【解决方案2】：

哈希集是专门为这类任务设计的，在这种任务中，您有唯一的值，您需要比较它们。

列表，不是。它们只是任意集合。

我的第一个调用端口是使用 HashSet 以及随之而来的各种交集方法。

【讨论】：

以下是 List 与 HashSet 的一些性能统计数据：stackoverflow.com/questions/150750/hashset-vs-list-performance
我确实对 Hashset 有疑问。当您使用“Hashet.ContainsKey”时。问题是需要在 Hashset 中找到与单个键的部分匹配。因此，我必须将哈希集键拆分为多个字符串（文件名/rev/version/location 等的一项）。然后搜索（假设这是可能的）。我在正确的道路上吗？也对编辑感到抱歉，我是在 SO 上制作 cmets 的新手。
好的，所以我将所有内容都转换为哈希表，并按照建议使用 intersect。唯一的问题是包含所有对象的文件具有我想要的某些信息。因此，当我读入时，我对每一行应用了一个正则表达式以删除我需要的内容（并匹配文件 2 的输入）。这将使我克服我的第一次冲击，稍后我将需要稍微推进我的正则表达式以收集我需要的所有信息。谢谢大家的帮助。我可以在一分钟内匹配所有 1300 个项目。

【解决方案3】：

第一站，不要使用列表。使用 HashSet 更快地插入和比较。

接下来，确定列表是否按预先排序的顺序排列，如果是，那么您可以快速同时读取两个文件，并且只需遍历每个文件，而不必将它们保存在内存中完全没有。

如果所有其他方法都失败了，请考虑使用 LINQ 的 Intersects 方法，它的性能可能会比您自己开发的版本好得多。

【讨论】：

【解决方案4】：

似乎已经指出了一些瓶颈。

如果我理解正确，您是：

将两个文件读入 2 个列表。 O(K)
遍历一个列表 (O(n)) 并在另一个列表中搜索匹配项 (O(m))。
创建一个包含这些匹配项的新列表。 (O(n))

所以你有一些命令：O(K + m * n * n)。瓶颈发生在第 2 步和第 3 步（代码中的内循环）。

解决方案：

您正在搜索的集合（我认为slAllObjects）应该是您可以快速搜索的对象，因此可以使用散列集或对其进行一次排序，然后使用二进制搜索来查找此集合中的项目。
预分配您正在创建的列表。您事先知道大小，因此请将容量设置为匹配。

如果您使用哈希集，则此解决方案应将 O(n^2) * O(m) 减少到 O(n) * O(k)，如果您对列表进行排序，则应将 O(n) * log(m) 减少。

【讨论】：

【解决方案5】：

除了已经提出的建议之外，我会考虑使用树木。如果我理解正确，文件名中有某种层次结构（即：服务器、文件路径、文件名等），对吧？通过使用树，您可以大大减少每一步的搜索空间。

此外，如果您在每个节点中使用Dictionary<String, Node>，则可以减少搜索时间，考虑到层级数量恒定，搜索时间变为O(1)。

此外，如果您决定使用数组或数组列表，请避免使用 foreach 并使用 for，因为它应该更快（不使用迭代器，因此，至少对于数组列表，应该更快）。

如果有什么不清楚的地方请告诉我。

【讨论】：