※ 引述《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機制下去...
內部怎麼處理怎麼跑完全無從認識....