LINQ 性能分析

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

  LINQ 基础示例

Dim Collection As String() = {"Beijing", "Shanghai", "Guangzhou", "Shenzhen", "Shijiazhuang", "Tianjin", "Taiyuan}
Console.WriteLine((From City In Collection Where City(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 性能测试: 获取随机数组数据

Sub Main()
        Dim Start As Integer
        For Count As Integer = 0 To 2
            Dim Random As New Random
            Dim TempArray As New List(Of Integer)
            '生成测试数组
            For I As Integer = 0 To 50000
                TempArray.Add(Random.Next(10000, 99999))
            Next
            '进行测试查询
            Dim Source As Integer() = TempArray.ToArray
            '计算时间
            '获取最后一条
            Start = Timer
            Dim Last As Integer, First As Integer, Length As Integer
            For I As Integer = 0 To 500000
                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
            For I As Integer = 0 To 500000
                Last = Source(Length - 1)
                First = Source(0)
                Length = Source.Length
            Next
            System.Console.WriteLine("传统查询数组首末与统计耗时: " & Math.Abs(Timer - Start) * 1000 & " 毫秒")
        Next
    End Sub
  程序运行于 Release 模式下,连续测试3次。测试结果如下:

  Linq 查询数组首末与统计耗时: 2109.375 毫秒
  传统查询数组首末与统计耗时: 296.875 毫秒
  Linq 查询数组首末与统计耗时: 2406.25 毫秒
  传统查询数组首末与统计耗时: 406.25 毫秒
  Linq 查询数组首末与统计耗时: 2156.25 毫秒
  传统查询数组首末与统计耗时: 218.75 毫秒

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

   本文作者保留全部权力,禁止用于商业用途,非商业用途转载请附加 www.soobb.com链接。

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值