Linq、lambda - 哪个语句更快？
我想知道哪种表达更快，哪种表达更受欢迎：
myList.Select(a => a.Property)
.Where(a => !String.IsNullOrEmpty(a))
myList.Where(a => !String.IsNullOrEmpty(a.Property))
.Select(a => a.Property)
当然为什么？
一般来说，我的问题是：我应该使用 Where 后跟 Select 还是 Select 后跟 Where ？
I was wondering which expression is faster and which one is preferred:
myList.Select(a => a.Property)
.Where(a => !String.IsNullOrEmpty(a))
myList.Where(a => !String.IsNullOrEmpty(a.Property))
.Select(a => a.Property)
and of course why?
Generally my question is: should I use Where followed by Select or Select followed by Where?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
没有人能知道，你必须衡量。考虑一个包含 50 个项目的列表，其中 40 个项目满足过滤条件。
项目然后过滤，这种方法最大限度地减少了对a.Property的访问次数。 100 次匿名方法调用和 50 次属性访问。
过滤然后投影，这种方法最大限度地减少了对匿名方法的调用次数。 90 次匿名方法调用和 90 次属性访问。
由于我们不知道您的属性的实现成本与匿名方法调用的成本，因此无法推断性能差异。
No one can know, you must measure. Consider a list of 50 items, with 40 items meeting the filter criteria.
Project then filter, this approach minimizes the number of accesses to a.Property. 100 anonymous method invocations and 50 property accesses.
Filter then project, this approach minimizes the number of calls to anonymous methods. 90 anonymous method invocations and 90 property accesses.
Since we don't know the costs of your property's implementation vs the costs of an anonymous method invocation, there's no way to reason about the performance difference.
我更喜欢第二种，首先过滤数据（使用
Where），然后选择（使用Select）您想要的数据。根据您要过滤的数据，性能可能会有所不同，但我觉得第二个更流畅。
I would prefer the second one, where you filter the data first (using
Where) and then select (usingSelect) what data you want.Depending on the data you are filtering performance may vary, but I feel the second one is more in flow.
这取决于 Linq 提供商。
例如，在 Linq2Sql 中，两个语句是相同的，因为 thwy 将针对数据库生成相同的 SQL。
在 Linq2Objects 中，它的执行方式可能有所不同。
It depends on the Linq provider.
For example in Linq2Sql both statements are the same since thwy will generate the same SQL against the database.
In Linq2Objects it may perform diferently.
没关系。在上述情况下，“查询”的其余部分仅引用投影数据，您也可以先投影，然后过滤。
请注意，并不是先过滤就一定更快；而是先过滤。通过首先调用
Select，您将执行更少的属性访问器 - 但无论哪种方式，差异可能都很小。如果您要编写更复杂的查询，我建议尽快缩小数据范围，在本例中这意味着在
WhereSelect >：这会导致代码较短，在较长的查询中更具可读性：毕竟，通过仅关注相关位（此处为字符串），读者可以忽略查询其余部分中包含它们的更复杂的对象。然而，对于如此小的查询来说，这个优势是相当没有意义的。It doesn't much matter. In cases such as the above, where the remainder of the "query" only references the projected data, you may as well project first and then filter.
Note that it's not the case that filtering first is necessarily faster; by calling
Selectfirst you will be executing fewer property accessors - but the difference is likely to be minor either way.If you're going to write more complex queries, I suggest writing reducing the scope of the data as quickly as you can, which in this case means writing the
Selectbefore theWhere: that results in shorter code which is more readable in longer queries: after all, by focusing only on the relevant bits (here strings) the reader can ignore the more complex objects containing them in the rest of the query. This advantage is fairly pointless for such a small query, however.