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

OStack程序员社区-中国程序员成长平台 › 门户 › 编程› Node.js›Node.js教程

原作者: [db:作者] 来自: [db:来源] 收藏邀请

最近写了几篇《c#扩展方法奇思妙用》的文章，一直只是讨论如何扩展、如何使用的问题，几乎没有涉及效率方面。
而大家的回复好多都在问效率如何、性能怎样，也引起了我对效率的关注，今天将初步测试的结果发出来，大家一起探讨一下。

以前没太写过性能测试的代码，上网找了一下，说可以用Stopwatch进行计时，比较准确。
Stopwatch使用比较简单，几个方法从名字上就知道用用途：Reset(计时清零)、Start(开始计时)、Stop(停止计时)，属性ElapsedMilliseconds就是执行操作所用的毫秒数。

为了简化测试，让更多人看明白，我们这是对IsNullOrEmpty扩展进行测试，它只是简单调用string.IsNullOrEmpty静态方法。
但为了让我们的测试更有趣一些，我们再加上两个相同功能的方法，一个是IsNullOrEmpty的手工实现版，称为手工方法，另外一个用lambda表达式写的。
一共是如下三个方法与string.IsNullOrEmpty（称为“原方法”）比较：

1         //扩展方法
2         public static bool IsNullOrEmpty1(this string s)
3         {
4             return string.IsNullOrEmpty(s);
5         }
6         //手工方法
7         public static bool IsNullOrEmpty2(string s)
8         {
9             return s == null || s == string.Empty;
10         }
11         //lambda方法
12         public static Func<string, bool> IsNullOrEmpty3 = s => string.IsNullOrEmpty(s);

我们在函数名后面添加上一个数字，将它们区分开，以避免相互混淆。

为了测试公正，尽量消除测试中的误差，我们采用一个数组存放要测试的字符串。
这个数组中存放三种字符串，非Empty非Null、Empty、Null。随机存入，数量大致相同。生成算法如下:

1         private static string[] GetTestStringArray(int count)
2         {
3             string[] result = new string[count];
4             Random random = new Random();
5
6             int r = 0;
7             for (int i = 0; i < count; i++)
8             {
9                 r = random.Next(3);
10                 if (r == 0) result[i] = i.ToString();
11                 else if (r == 1) result[i] = string.Empty;
12                 else result[i] = null;
13             }
14             return result;
15         }

我们让这四个算法（前面三个算法+原来的静态算法）依次对数组中的每一项进行判断。
有一点要特别注意，对集合遍历也要耗时，我们要排除这段时间。
下面给出测试算法，写的不好，别见笑：

1public static void Test()
2

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

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

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

上面这句代码是基本循环，后面三组代码都在它基础上加入相应操作。
Test()不复杂，就是太啰嗦，大家都看得明白。

先在Debug模式下执行测试：

后面三个方法效率也太低了吧！！且一放，再看Release模式：

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

说明一：项目的输出类型必需是“控制台应用程序”才能在控制台中输出。
说明二：控制台的宽度比较小，我删除了Test()中输出中的几个制表符等，才让它输入不换行。
说明三：本处执行的是Release模式生成的程序，而不是Debug模式生成的程序。

Debug和Release测试是在VS2008宿主中进行的，最后控制台测试才是真正的实际运行环境，我们测试结果以控制台测试结果为准。
之所以将前面两个贴出来，是告诉大家在vs中调试测试的结果是相当不准确的。

我们来分析下测试的结果吧：
1.扩展方法的效率是相当高的，与原方法只有百分之几（多运行几次，可能是1、3、4甚至0，还有一次是-2，即比值为0.98）的性能损失。
2.手工方法效率最低，低得出乎大多数人的意料。
3.lambda会带来“可观”的性能损失。

如果考虑性能：可以使用扩展方法，但扩展方法内部不要使用lambda表达式，其内部尽量使用常规代码。
（其实扩展方法内部代码简洁与否无所谓，毕竟扩展方法是一种封装，可以将内部复杂的操作隐藏起来并以一个简单的扩展方法提供给调用者）
如果考虑性能：少用lambda，多用原生方法。

感觉：这次测试的结果令我倍感意外，确实没想到扩展方法的效率如此之高（看来我的扩展想法有市场了）！
期望：本人是“粗人”，很不细心，大家如果发现上面测试中有错误，请马上告知我，谢谢！
打算：对一个扩展方法的测试说服力不够，以后会再做一些相关测试工作。
感慨：效率的高低不是眼睛看看、脑子想想能断定的，而必需采用科学的测试方法才可以给出结论。
（讨论，如果本文只给出在debug及release下的测试结果，会是怎样的呢？）

本人系列文章《