考虑现在我有一个private的ArrayList用于保存用户在TextBox里面输入的字符串，很明显TextBox.Text里面就是返回一个string类型的对象，并且也不可能是null（或者说我通过在初始化的时候给它赋一个string.Empty来避免出现null的情况）。现在我需要将这些保存在那个ArrayList里面的字符串通过BinaryWriter保存到一个自定义格式的二进制文件里面，当然也可能有其他的计算需要我把ArrayList里面的字符串数据进行计算或者处理，这里为了简便随便说了一个也许不是很完整也不是很合理的的例子，但是我相信大家应该明白我的意思了。Hmm，也许还需要另外一个限定，就是没有Generic的支持，比如说这个东西需要在.NET Compact Framework里面实现，而.NET CF即使是到了2.0的版本也不会有Generic的支持。
但是上一次Ninputer说了：
假如o里面原来就是String类型，那么循环100000000的结果是
(string)o 为610ms
o.ToString() 为670ms
这种差距几乎没有意义。
假如o里面是除string之外的其他类型，那么o根本不能直接cast成String。
而同时也有人说，强制转换比ToString要快。那么实际情况是如何呢？请大家先来看看我的代码：
private string testString; private const int testRound = 100000000; private void button1_Click(object sender, System.EventArgs e)
{
object o = "Hello! this is a test!"; int i; long dt; dt = DateTime.Now.Ticks; for (i = 0; i < testRound; i++)
{
testString = (string)o;
} dt = DateTime.Now.Ticks - dt; textBox1.Text = dt.ToString("#,###,###,###"); Application.DoEvents(); dt = DateTime.Now.Ticks; for (i = 0; i < testRound; i++) { testString = o.ToString(); } dt = DateTime.Now.Ticks - dt; textBox2.Text = dt.ToString("#,###,###,###"); Application.DoEvents();
}
这个实验我分别在VS2k3和VS2k5里面实验过，并且分别用Debug和Release两种模式去测试，测试结果如下：
DEBUG: （强制转换：ToString）
@2k3
11,406,250 : 123,125,000
@2k5
10,468,750 : 123,906,250
RELEASE:
@2k3
12,500,000 : 118,593,750
@2k5
7,031,250 : 13,906,250
大家首先会发现如下结论：
1、强制转换的速度在0.7秒到1.3秒之间，而ToString则基本上处于10秒以上的级别（有特例）。所以我极度怀疑Ninputer的测试结果是错误的，因为他的两个结果都是在0.6秒左右，当然还有一个特例跟Ninputer的数据相对接近，但是请继续看下面的结论。
2、这里有一个唯一的特例，就是VS2k5的Release模式，大家可以看到ToString的速度从10秒级别急剧减少为1秒级别，这个就是我题目所说的意外惊喜。但是即使是这样，ToString仍然比强制转换慢了50%，同时该数据还是P4HT 2.8GHz 1G Ram的机器上面测得，如果要ToString达到Ninputer所说的数据，我估计得要P4HT 4GHz以上的CPU，或者P4HT双CPU才有机会。还有，Ninputer的数据仅仅相差10%左右，这个跟我的实测数据完全不吻合。因此我估计Ninputer的测试很可能是因为代码不合理，被JIT短路了（优化了），如果将转换结果保存在全局变量里面，也许就不是这个结果了。
关于为什么VS2k5的ToString在Release模式下面会有这么大的性能提升，我想还需要另外做实验去证明，现在还不好胡乱发言（虽然已经有自己的想法了）。
3、大家如果更加仔细的去看强制转换的数据，就会发现VS2k5无论在哪一种情况下面，都会比VS2k3的数据要快那么一点点，大约10%到30%不等。关于这个我可以马上给大家一个解释，这个实际上是.NET Framework 1.x和2.0之间的问题，但是这需要观察JIT之后的Native Asm，难度有点高。请看片断：
.NET Framework 1.1:
testString = (string)o;
00000063 mov edx,dword ptr [ebp-0Ch]
00000066 mov ecx,79BF9AF8h
0000006b call 71E608BC
00000070 lea edx,[ebx+000000ECh]
00000076 call 7204C590
.NET Framework 2.0:
testString = (string)o;
0000007c test ebx,ebx
0000007e je 0000009A
00000080 cmp dword ptr [ebx],788ED668h
00000086 jne 0000008C
00000088 mov eax,ebx
0000008a jmp 00000098
0000008c mov edx,ebx
0000008e mov ecx,788ED668h
00000093 call 75621D76
00000098 jmp 0000009C
0000009a mov eax,ebx
0000009c mov esi,dword ptr [ebp-40h]
0000009f lea edx,[esi+00000104h]
000000a5 call 7561BBB0
在这里大家可以清楚地看到，.NET Framework 1.1 仅仅是简单的将强制转换交给一个函数来处理（红色部分），但是2.0则首先进行了一些简单的处理，例如先判断是否是null（test ebx, ebx），以及判断o是否就是恰好string类型而不是string的子类型（cmp dword ptr [ebx], 788ED668h）。当然了，string是一个sealed的类型所以明显不可能有子类型，如果我要求强制转换成Form呢？如果这两项都失败了，才会和1.0里面一样调用一个函数来判断。所调用的函数实际上是将ebx所引用的对象里面的类型向上查找其父类型，看看有没有string类型（788ED668h），可以预见这是一个相对较为耗时的操作。而在我们实际的应用里面，如果进行强制转换通常都是直接转化成他的实际类型的，因此这一小段代码能够较为明显的提高系统的性能。不过这里也可以看到，优化过程还是做的不够，应该将86到8a这三句简化成一句je 0000009A。
我们再来看看ToString的情况。由于ToString是一个virtual的函数，被string类型override了，因此必然需要查v-table来进行正确调用。通过查看.NET Framework 1.1 所JIT出来的代码，可以清楚地看到这一点：
testString = o.ToString();
00000108 mov edi,ebx
0000010a mov ecx,dword ptr [ebp-0Ch]
0000010d mov eax,dword ptr [ecx]
0000010f call dword ptr [eax+28h]
00000112 mov esi,eax
00000114 push esi
00000115 mov ecx,edi
00000117 mov edx,995358h
0000011c call 71E7021D
这里ebx指向object o的类型描述，ebp - 0Ch指向object o对象本身（其实这里的负偏移12个字节就是类型描述，两者实际上是完全紧挨着的），其第一个dword就是string类型本身的数据（不是实例的数据）。我并不是非常清楚里面的一些实现，通过观察，估计可能里面包括了本类型的一些描述，父类型和接口的描述，里面偏移0x28应该就是vtable的实质内容（估计），其第一个就是指向ToString实际函数地址的指针。后面一个调用估计应该是一个赋值调用，和ToString调用可能没有太大的关系。为了证实我的想法，我甚至跟踪到第一个调用内部，发现确实是到了string.ToString()里面（大家可以看Disassembly页的Address下拉框，里面现实的是System.String.ToString），其代码如下：
00000000 push esi
00000001 mov esi,ecx
00000003 mov eax,esi
00000005 pop esi
00000006 ret
分析到这里，我仍然不能够确定为什么ToString比强制转换性能相差10倍的原因。如果非要我估计一下，那么我会这么比较：
强制转换一共经历了：两个“比较+条件转移”，一个寄存器间赋值，一个索引器加偏移到寄存器赋值，一个普通调用（内部经历过程已经在前面分解了），一个赋值调用（内部无法分析）。
ToString一共经历了：5个寄存器间赋值，一个常数到寄存器赋值，两个间接（加偏移）地址到寄存器赋值，一个寄存器压栈，一个寄存器加偏移量间接地址调用（内部已经在前面分解了），以及一个赋值调用（内部无法分析）。
除去无法分析的部分，ToString比强制转换多出将近一倍的汇编指令，并且还包括比较耗时的间接地址赋值调用指令。光是这个差别，估计就应该有至少150%的性能损失。但是现在性能相差接近10倍，难道是仅仅因为那几句间接寻址的指令造成的？那就有点不可思议了。其实我有点怀疑ToString后面第二个调用内部有一些损失性能的指令（也许是多余的指令），如果我们看看.NET 2.0 Release版本的数据，也许是应该这么解释吧？有关这个问题需要做更多的研究……
嗯，今天的Post的正式内容到此结束。PS一下：
1、twodays在cnblogs里面的Post里面回复说：
“o.ToString() 实际上是调用了从object继承出来的ToString()虚函数，这一个虚函数在string类型里面被重写，代码如下：”
不对，因为你的o这会儿本来类型就是object，而不是string，所以他调用的实际上应该是object的ToString方法里面的内容，经过Reflector查看，里面的内容是：
return this.GetType().FullName;
这里我可以明确地告诉你，你错了（包括后面表示赞同的“小新0574”），至于为什么我会另外在一篇Post里面给出解释，因为这两个问题的难度级别相差太大了，在这里写也许很多朋友已经看得迷迷糊糊的了，继续看下去效果不好。
2、我记得有人在上一个Post里面问过as操作性能如何，我也做过试验了，性能没有差别，至少用肉眼观察数据结果是看不出来的。也许在Disassembly层会有细微差别，但是我没有兴趣再研究下去了。
3、有人说自己写的类里面ToString()可能会抛出Exception的问题，其实我是这么认为的。如果你在代码里面抛出Exception的话，那应该是一件相当遗憾的事情。因为ToString()没有任何参数，不可能因为参数问题引起异常。同时ToString函数的含义是，安全的返回关于该实例的信息，因此从感情上来说就不应该出现Exception的情况。很多时候我们就是利用ToString的一些特性来完成一些简单的事情，例如在ListBox里面加入一个不是String的对象，但显示的是用户能够理解的信息，这样用户方便选择，我们则方便编写代码。如果你的类会在ToString里面抛出异常，那么整个程序就会因此而不稳定。总之我认为在ToString() 里面抛出异常并不是这个函数存在的本意。
