5

在处理一个项目时,我遇到了以下代码,它引发了性能标志。

foreach (var sample in List.Where(x => !x.Value.Equals("Not Reviewed")))
{
    //do other work here
    count++;
}

我决定运行几个快速测试,将原始循环与以下循环进行比较:

foreach (var sample in List)
{
    if (!sample.Value.Equals("Not Reviewed"))
    {
        //do other work here
        count++;
    }
}

并把这个循环也扔进去看看会发生什么:

var tempList = List.Where(x => !x.Value.Equals("Not Reviewed"));
foreach (var sample in tempList)
{
    //do other work here
    count++;
}

我还以 3 种不同的方式填充了原始列表:50-50(所以 50% 的值是“未审查”,其余的是其他值)、10-90 和 90-10。这些是我的结果,第一个和最后一个循环基本相同,但第二个循环要快得多,尤其是在 10-90 的情况下。为什么?我一直认为Lambda有很好的表现。

编辑

count++实际上并不是循环内部的内容,我只是在此处添加了用于演示目的,我想我应该使用“//在这里做点什么”

性能结果

编辑 2

每个运行 1000 次的结果: 性能结果 1000 次

4

1 回答 1

9

基本上,有少量额外的间接性——既用于通过委托的测试,也用于迭代部分。考虑到每次迭代所做的工作很少,额外的间接操作相对昂贵。

在我看来,这既不奇怪也不令人担忧。如果您在现实世界的应用程序中处于非常重要的罕见情况下,那么您可以轻松地执行这种微优化。以我的经验,这种循环很少会成为应用程序中的重要瓶颈。正常的做法应该是:

  • 定义性能要求
  • 以最清晰、最简单的方式实现功能需求
  • 根据要求衡量您的绩效
  • 如果发现性能不佳,请调查原因,并尽可能远离清晰,尽可能获得最大的“物有所值”
  • 重复直到完成

回复编辑:

count++ 实际上并不是循环内部的内容,我只是在此处添加了出于演示目的,我想我应该使用“//在此处执行某些操作”

嗯,这很重要——那里完成的工作越多,其他任何事情就越不重要。只是计数是相当快的,所以我预计会看到很大的差异。做任何数量的实际工作,差异会更小。

于 2013-07-18T15:42:26.743 回答