Type casting impact over execution performance in C#
http://tinyurl.com/clr68dj
這是篇 2004 年的文章, 也就是 .NET Framework 1.1 時代,
作者的程式以及測試數據, 顯示 as 比起 cast 要來得快.
但, 我們也可以看到文章下方的留言, 2006 年有人指出在 .NET 2.0 上,
可能因為微軟實作及最佳化不同, 所以 cast 又比 as 快.
而後續也有數個留言提到這篇文章的結論有誤.
那在 .NET Framework 到了 4.6 的 2015 年, 又是什麼狀況呢?
測試平台: Windows 10 TH2 x64, Visual Studio 2015
先說總結: as 快於 cast . (*1)
方式 時間
as 3,231ms
down as 3,244ms
as + object 3,251ms
down as + object 3,229ms
cast 3,246ms
down cast 4,341ms
cast + object 6,485ms
down cast + object 4,310ms
測試用的 method, 只列出兩個例子:
static void MethodCastObject(object c)
{
for (int i = 0; i < int.MaxValue; i++)
{
Parent p = (Parent)c;
p.DoSomething();
}
}
static void MethodAsDown(Parent p)
{
for (int i = 0; i < int.MaxValue; i++)
{
Child c = p as Child;
c.DoSomething();
}
}
*1, 但若要說 cast 快於 as, 也並不是完全不對. 理由是: ......

我還以為這種東西，會被轉譯成一樣的語法，原來不是嗎?

(p as Child).DoSomething() 呢?

兩者用不同的MSIL opcode, as: isinst, cast: castclass樓上這種寫法, 對 compiler 來說是沒什麼差別的.

請勾選最佳化(或選Release方案)後直接執行，或用Ctrl+F5他們最後call的mscorwks不一樣，會導致編譯出來的x86 asm差蠻多的。說到這個必須要提一下，.net Framework 4.0大幅優化了x64版本的as，但x86並沒有受惠。更正一下，編譯出來的x86 asm，應該要說"執行的"比較確實

原文中就已經提到 As 在編譯階段就已經判斷過是否可以轉型，所以在執行階段就可以略過某些例外檢查，所以說 As 比 Cast 快是很合理的結果！

如果討論這種問題時,還要先講選擇 Release mode,或是選擇Start Without Debugging,就有點令人莞爾了..要說 .NET 4 之後大幅優化 x64 的 as, 卻沒讓 x86 受惠,這論述有問題,而且跟實際狀況是有矛盾的.to jizang, 原文沒這樣寫吧.

http://i.imgur.com/WmYjCV7.png對不起我資質駑鈍，既看不出你原文有提測試環境，也看不出編譯目標平台，我還是退下以免丟人現眼。^最佳化