※ 引述《iterator (rotareti)》之铭言：
: 作者的程式以及测试数据, 显示 as 比起 cast 要来得快.
: 但, 我们也可以看到文章下方的留言, 2006 年有人指出在 .NET 2.0 上,
: 可能因为微软实作及最佳化不同, 所以 cast 又比 as 快.
: 而后续也有数个留言提到这篇文章的结论有误.
: 那在 .NET Framework 到了 4.6 的 2015 年, 又是什么状况呢?
不知道你对这有兴趣想讨论的目的为何?
最快的方式就是实际跑出来怎样就怎样就可以了,
顶多再深入可以看看编译出来中介码看看差异...
说真的这种比速度的问题,因为个人需要,也做过类似测试,
影响到的包括执行为x86或是x64模式.RAM的速度.编译器选项.
编译器版本.执行环境可能都会有影响.
有时候你觉得先把结果算成TABLE,靠查表可能比较快,
结果查表就是比较慢,因为内存一次存取的时间甚至会慢于你直接重算一次..
有时候你直觉X64应该会比传统X86跑得比较快,但结果就是X64跑得比较慢,
有时候DEBUG模式下两者速度差不少,一般正常执行模式加最佳化后,两者又差不多,
一大堆有的没的....
So?? StopWatch + loop 跑看看 结果怎样就怎样䁖
甚至为了加速考虑直接写.net的IL Code,后来想想走火入魔了,也未必好到哪里去..
回归到本质上,如果真在效率上有极端需求,不是就直接玩c/c++或是直接写组语了吗?
或是把重要费时的部分核心至少用c/c++写成dll呼叫.
.NET 你在这种编译性质上的部分钻牛尖,不然就干脆钻到IL层或是JIT议题上去,
不然怎样钻,一旦变成IL code都是黑盒子,且一旦搭配jit机制下去...
内部怎么处理怎么跑完全无从认识....