WEB开发网
开发学院软件开发C语言 c#扩展方法奇思妙用性能篇一:扩展方法性能初测 阅读

c#扩展方法奇思妙用性能篇一:扩展方法性能初测

 2010-09-30 20:50:36 来源:WEB开发网   
核心提示: 想重构一下,考虑了几种办法,c#扩展方法奇思妙用性能篇一:扩展方法性能初测(3),不太好,怕重构后大家看起来更费力,而必需采用科学的测试方法才可以给出结论,(讨论,Test中的4个小段代码很相似,分别用来测量4个算法的用时

想重构一下,考虑了几种办法,不太好,怕重构后大家看起来更费力。

Test中的4个小段代码很相似,分别用来测量4个算法的用时。

1     foreach (string s in ss) str = s;

上面这句代码是基本循环,后面三组代码都在它基础上加入相应操作。

Test()不复杂,就是太啰嗦,大家都看得明白。

先在Debug模式下执行测试:

c#扩展方法奇思妙用性能篇一:扩展方法性能初测

后面三个方法效率也太低了吧!!且一放,再看Release模式:

c#扩展方法奇思妙用性能篇一:扩展方法性能初测

比前面效率提高了一些。最后是把Release模式下生成的程序,放在命令行中执行:

c#扩展方法奇思妙用性能篇一:扩展方法性能初测

说明一:项目的输出类型必需是“控制台应用程序”才能在控制台中输出。

说明二:控制台的宽度比较小,我删除了Test()中输出中的几个制表符等,才让它输入不换行。

说明三:本处执行的是Release模式生成的程序,而不是Debug模式生成的程序。

Debug和Release测试是在VS2008宿主中进行的,最后控制台测试才是真正的实际运行环境,我们测试结果以控制台测试结果为准。

之所以将前面两个贴出来,是告诉大家在vs中调试测试的结果是相当不准确的。

我们来分析下测试的结果吧:

1.扩展方法的效率是相当高的,与原方法只有百分之几(多运行几次,可能是1、3、4甚至0,还有一次是-2,即比值为0.98)的性能损失。

2.手工方法效率最低,低得出乎大多数人的意料。

3.lambda会带来“可观”的性能损失。

如果考虑性能:可以使用扩展方法,但扩展方法内部不要使用lambda表达式,其内部尽量使用常规代码。

(其实扩展方法内部代码简洁与否无所谓,毕竟扩展方法是一种封装,可以将内部复杂的操作隐藏起来并以一个简单的扩展方法提供给调用者)

如果考虑性能:少用lambda,多用原生方法。

感觉:这次测试的结果令我倍感意外,确实没想到扩展方法的效率如此之高(看来我的扩展想法有市场了)!

期望:本人是“粗人”,很不细心,大家如果发现上面测试中有错误,请马上告知我,谢谢!

打算:对一个扩展方法的测试说服力不够,以后会再做一些相关测试工作。

感慨:

效率的高低不是眼睛看看、脑子想想能断定的,而必需采用科学的测试方法才可以给出结论。(讨论,如果本文只给出在debug及release下的测试结果,会是怎样的呢?)

上一页  1 2 3 

Tags:扩展 方法 奇思

编辑录入:爽爽 [复制链接] [打 印]
赞助商链接