Lambda表达式：要性能还是要清晰的代码？

在上文的***个示例中，我们演示了如何使用Lambda表达式配合.NET 3.5中定义的扩展方法来方便地处理集合中的元素（筛选，转化等等）。不过有朋友可能会提出，那个“普通写法”并非是性能***的实现方法。方便起见，也为了突出“性能”方面的问题，我们把原来的要求简化一下：将序列中的偶数平方输出为一个列表。按照那种“普通写法”可能就是：

武宣网站建设公司创新互联公司,武宣网站设计制作，有大型网站制作公司丰富经验。已为武宣上千多家提供企业网站建设服务。企业网站搭建\外贸网站建设要多少钱，请找那个售后服务好的武宣做网站的公司定做！

 
 
 
  
  
  static List< int> EvenSquare(IEnumerable< int> source)    
  
  {    
  
      var evenList = new List< int>();    
  
      foreach (var i in source)    
  
      {    
  
          if (i % 2 == 0) evenList.Add(i);    
  
      }    
  
     
  
      var squareList = new List< int>();    
  
      foreach (var i in evenList) squareList.Add(i * i);    
  
     
  
      return squareList;    
  
  }

从理论上来说，这样的写法的确比以下的做法在性能要差一些：

 
 
 
  
  
  static List< int> EvenSquareFast(IEnumerable< int> source)    
  
  {    
  
      List< int> result = new List< int>();    
  
      foreach (var i in source)    
  
      {    
  
          if (i % 2 == 0) result.Add(i * i);    
  
      }    
  
     
  
      return result;    
  
  }

在第二种写法直接在一次遍历中进行筛选，并且直接转化。而***种写法会则根据“功能描述”将做法分为两步，先筛选后转化，并使用一个临时列表进行保存。在向临时列表中添加元素的时候，List< int>可能会在容量不够的时候加倍并复制元素，这便造成了性能损失。虽然我们通过“分析”可以得出结论，不过实际结果还是使用CodeTimer来测试一番比较妥当：

 
 
 
  
  
  List< int> source = new List< int>();    
  
  for (var i = 0; i <  10000; i++) source.Add(i);    
  
     
  
  // 预热    
  
  EvenSquare(source);    
  
  EvenSquareFast(source);    
  
     
  
  CodeTimer.Initialize();    
  
  CodeTimer.Time("Normal", 10000, () => EvenSquare(source));    
  
  CodeTimer.Time("Fast", 10000, () => EvenSquareFast(source));

我们准备了一个长度为10000的列表，并使用EvenSquare和EvenSquareFast各执行一万次，结果如下：

 
 
 
  
  
  Normal    
  
          Time Elapsed:   3,506ms    
  
          CPU Cycles:     6,713,448,335    
  
          Gen 0:          624    
  
          Gen 1:          1    
  
          Gen 2:          0    
  
     
  
  Fast    
  
          Time Elapsed:   2,283ms    
  
          CPU Cycles:     4,390,611,247    
  
          Gen 0:          312    
  
          Gen 1:          0    
  
          Gen 2:          0

Lambda表达式的执行：性能比对与结论

结果同我们料想中的一致，EvenSquareFast无论从性能还是GC上都领先于EvenSquare方法。不过，在实际情况下，我们该选择哪种做法呢？如果是我的话，我会倾向于选择EvenSquare，理由是“清晰”二字。

EvenSquare虽然使用了额外的临时容器来保存中间结果（因此造成了性能和GC上的损失），但是它的逻辑和我们需要的功能较为匹配，我们可以很容易地看清代码所表达的含义。至于其中造成的性能损失在实际项目中可以说是微乎其微的。因为实际上我们的大部分性能是消耗在每个步骤的功能上，例如每次Int32.Parse所消耗的时间便是一个简单乘法的几十甚至几百倍。因此，虽然我们的测试体现了超过50%的性能差距，不过由于这只是“纯遍历”所消耗的时间，因此如果算上每个步骤的耗时，性能差距可能就会变成10%，5%甚至更低。

当然，如果是如上述代码那样简单的逻辑，则使用EvenSquareFast这样的实现方式也没有任何问题。事实上，我们也不必强求将所有步骤完全合并（即仅仅使用1次循环）或完全分开。我们可以在可读性与性能之间寻求一种平衡，例如将5个步骤使用两次循环来完能是更合适的方式。

说到“分解循环”，其实这类似于Martin Fowler在他的重构网站所上列出的重构方式之一：“Split Loop”。虽然Split Loop和我们的场景略有不同，但是它也是为了代码的可读性而避免将多种逻辑放在一个循环内。将循环拆开之后，还可以配合“Extract Method”或“Replace Temp with Query”等方式实现进一步的重构。自然，它也提到拆分后的性能影响：

You often see loops that are doing two different things at once, because they can do that with one pass through a loop. Indeed most programmers would feel very uncomfortable with this refactoring as it forces you to execute the loop twice - which is double the work.

But like so many optimizations, doing two different things in one loop is less clear than doing them separately. It also causes problems for further refactoring as it introduces temps that get in the way of further refactorings. So while refactoring, don't be afraid to get rid of the loop. When you optimize, if the loop is slow that will show up and it would be right to slam the loops back together at that point. You may be surprised at how often the loop isn't a bottleneck, or how the later refactorings open up another, more powerful, optimization.

这段文字提到，当拆分之后，您可能会发现更好的优化方式。高德纳爷爷也认为“过早优化是万恶之源”。这些说法都在“鼓励”我们将程序写的更清晰而不是“看起来”更有效率。

以上便分析了使用C# Lambda表达式编码时需要优先考虑代码清晰度的理由。

当前题目：Lambda表达式：要性能还是要清晰的代码？
网页URL：http://www.shufengxianlan.com/qtweb/news48/495398.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源：创新互联

猜你还喜欢下面的内容