与数据视图相比，Linq 到对象的速度非常慢答案

【问题标题】：Linq to objects very slow compared to dataview与数据视图相比，Linq 到对象的速度非常慢
【发布时间】：2011-09-06 07:09:59
【问题描述】：

我是 Linq 的忠实粉丝，因为它的打字、清晰和简洁。但是我发现搜索匹配记录的速度比旧数据视图慢了大约 2000 倍！

我正在编写一个应用程序来备份大量文件 - 500,000 个文件和 500 GB 的数据。我在备份集中创建了一个文件清单，并将目录中的文件与清单中的文件进行比较，以记录已经备份的内容。这样我就知道哪些文件已更改，因此需要复制。

慢步是这个：

var matchingMEs = from m in manifest where m.FullName == fi.FullName select m;

其中manifest = List<ManifestEntry>和ManifestEntry是一个相对简单的POCO。

整体性能为每秒 17-18 条记录。

当我使用数据视图时：

DataView vueManifest = new DataView(dt, "", "FullName", DataViewRowState.CurrentRows);

然后在循环中找到带有 .FindRows 的匹配清单条目：

matchingMEs = vueManifest.FindRows(fi.FullName);

...那么我每秒可以处理大约 35,000 个文件！

这正常吗？我不敢相信 Linq 的价格如此之高。是 Linq 还是让事情变慢的对象？

（顺便说一句，我尝试使用Dictionary 和SortedList 以及List<ManifestEntries>，它们都给出了大致相同的结果。）

【问题讨论】：

如果您使用 Dictionary 得到相同的错误结果，我认为您未正确初始化它。请出示相应的代码。另外，请说明m.FullName 的实现。 fi 是什么类型的？更多：FindRows 返回所有匹配的行。您在此结果上的 foreach 循环不会进行任何搜索。与此相反，LINQ 使用延迟执行并将在您的 foreach 循环内执行搜索。要正确比较运行时，您需要将 LINQ foreach 与调用 FindRows + foreach 循环的持续时间进行比较。
这似乎不对。 ManifestEntry.FullName 在做什么？它是从文件加载的吗？
我认为您首先运行 linq 查询然后运行数据 grideview 查询，在这一步中，所有文件都已加载，因此数据网格可以快速运行，但如果您反转执行路径，您将得到另一个结果。
嗨，丹尼尔，卡梅伦； m.FullName 只是对象中的一个字符串：public string FullName { get; set; }。主循环foreach (FileInfo fi in Files) 围绕此匹配代码，因此 linq 查询或 FindRows 处于相同条件。

【解决方案1】：

您的 DataView 按全名排序，因此 FindRows 可以直接跳转到正确的记录，而您的 linq 查询必须遍历列表，直到到达正确的记录。如果您有 500,000 个条目，这肯定会很明显。

假设 fullname 是唯一的，那么当您切换到使用字典时，我怀疑您仍在使用类似的 linq 查询迭代它，例如

var matchingME = (from m in manifest where m.Key == fi.FullName select m).Single();

而你应该使用

var matchingME = manifest[fi.FullName] ;

【讨论】：

你的传奇@sgmoore！这（几乎）正是我减去.single() 所拥有的。不幸的是，我现在已经删除了对象的代码并替换为数据表。我意识到字典解决方案对我不起作用，因为文件可能不止一次出现在清单中 - 即 FullName 可能不是唯一的 - 在删除和修改文件副本的情况下。因此，即使使用您的解决方案，我仍然会被卡住。这是否仍然使 linq 高而干燥？
@RichieRich 你问'这是否仍然让 linq 变得又高又干？好吧，我不是如何实现 linq to objects 的专家，所以没有资格回答这个问题，但我不会在这种情况下使用它。如果我从 List 开始，我可能会使用 ToDictionary（如果键是唯一的），否则我会使用 ToLookup。