话说自从 Beta1 发布以来，关于 .Net Framework 3.5 的讨论真是沸沸扬扬。我大概也算是比较早吃螃蟹的一位，Beta1 发布伊始就将它用于正式的开发中。虽然其间遇到过许许多多的 BUG，对于 .Net Framework 3.5 的核心特性 - LINQ，我个人感觉还是相当满意的。然而仅仅是 LINQ 比较酷的语法，绝不足以决定项目所用的技术。事实上，如果不是我这种个人作坊式的开发，评估新技术是否采用很重要的一点，就是它的性能是否令人满意。如果您还不了解 LINQ，可以通过简单的 VB9 示例作出感性的认知。

　　LINQ 基础示例

DimCollectionAsString()={"Beijing","Shanghai","Guangzhou","Shenzhen","Shijiazhuang","Tianjin","Taiyuan}
Console.WriteLine((FromCityInCollectionWhereCity(0)="T").First)

　　在此要强调一点，绝不要把 LINQ 与 Linq to SQL(DLINQ) 混为一谈，DLINQ 仅仅是 LINQ 的一个应用，绝非 LINQ 的全部。与 LINQ 一同来到的是大量的编译器特性，不论是 C#3 或是 VB9，都有着许多令人耳目一新的新语法特性。然而，由于 .Net Framework 3.x 都是 .Net Framework 2 的超集，所以所有的语法特性都不过是编译时的翻译。如果您试图反编译 LINQ 表达式，Lambda 或匿名函数，您将见到大批的函数嵌套，不知名的函数与其他令人头昏脑涨的程序结构。这一切都是编译器代为完成的。您无需担心 C# 中的 Var，或是 VB 中的无需 As 的变量定义带来的装/拆箱问题，它们将在 IL 中被推断为真实的数据类型。

　　探讨 LINQ 的性能问题时，我们将不仅局限于简单的时间比较，还将对 LINQ 的实现代码进行简单的分析，并就 Linq to SQL 生成的 T-SQL 语句讨论优化数据库性能的方法。工欲善其事，必先利其器，此系列中测试的平台基于 SQL Server 2005 SP2，反编译工具采用 Lutz Roeder's Reflector。

　　言归正传。由于应用了扩展方法，LINQ 得以查询任何现有 IEnumerable(Of T) 的内容。但是，性能问题却被隐藏在通用性与易用性之下。让我们做一个简短的测试，测试是使用 LINQ 获取一个随机数字数组的开头，结尾与总计，并与传统方式按数组索引获取作出对比。测试代码如下：

　　Visual Basic 9 - LINQ 性能测试: 获取随机数组数据

SubMain()
　　　　DimStartAsInteger
　　　　ForCountAsInteger=0To2
　　　　　　DimRandomAsNewRandom
　　　　　　DimTempArrayAsNewList(OfInteger)
　　　　　　'生成测试数组
　　　　　　ForIAsInteger=0To50000
　　　　　　　　TempArray.Add(Random.Next(10000,99999))
　　　　　　Next
　　　　　　'进行测试查询
　　　　　　DimSourceAsInteger()=TempArray.ToArray
　　　　　　'计算时间
　　　　　　'获取最后一条
　　　　　　Start=Timer
　　　　　　DimLastAsInteger,FirstAsInteger,LengthAsInteger
　　　　　　ForIAsInteger=0To500000
　　　　　　　　Last=Source.Last
　　　　　　　　First=Source.First
　　　　　　　　Length=Source.Count
　　　　　　Next
　　　　　　System.Console.WriteLine("Linq查询数组首末与统计耗时:"&Math.Abs(Timer-Start)*1000&"毫秒")
　　　　　　'方法2:计算时间
　　　　　　Start=Timer
　　　　　　'获取最后一条
　　　　　　Length=Source.Length-1
　　　　　　ForIAsInteger=0To500000
　　　　　　　　Last=Source(Length-1)
　　　　　　　　First=Source(0)
　　　　　　　　Length=Source.Length
　　　　　　Next
　　　　　　System.Console.WriteLine("传统查询数组首末与统计耗时:"&Math.Abs(Timer-Start)*1000&"毫秒")
　　　　Next
　　EndSub

　　程序运行于 Release 模式下，连续测试3次。测试结果如下：

　　Linq 查询数组首末与统计耗时: 2109.375 毫秒

　　传统查询数组首末与统计耗时: 296.875 毫秒

　　Linq 查询数组首末与统计耗时: 2406.25 毫秒

　　传统查询数组首末与统计耗时: 406.25 毫秒

　　Linq 查询数组首末与统计耗时: 2156.25 毫秒

　　传统查询数组首末与统计耗时: 218.75 毫秒

　　看到这里，通用的 LINQ 与传统方法的差距就已明了。虽然仅仅是管中窥豹式的简单测试，但各位若无必要，还是尽量使用原生于数组的功能。当然，各位看官欲知为何差距如此之大，且听下回分解。水平有限，若有错谬，敬请谅解并指出。