※ 引述《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机制下去... 内部怎麽处理怎麽跑完全无从认识.... -- ※ 编辑: erspicu (60.248.56.181), 12/02/2015 14:12:48 ※ 编辑: erspicu (118.171.242.102), 12/02/2015 16:15:30 让我想到 微软在VS 2015有C#.NET的Native编译功能.....真正c#语法, 但接近Native或是Native效能,不过只能绑定在universal专案用... 其实我觉得微软若有心要做,把c#变成native编译本来技术上就满可行的... 毕竟都搞出了JIT了...可能是啥商业上的策略吧... ※ 编辑: erspicu (118.171.244.172), 12/04/2015 16:52:55