沒(méi)有額外的IL代碼var
關(guān)鍵字:對(duì)于非匿名類型,產(chǎn)生的IL應(yīng)該是相同的。如果編譯器無(wú)法創(chuàng)建該IL,因?yàn)樗鼰o(wú)法確定您打算使用哪種類型,那么您將得到一個(gè)編譯器錯(cuò)誤。
唯一的訣竅是var
如果要手動(dòng)設(shè)置接口或父類型,則將推斷該類型的確切類型。
8年后更新
我需要更新這一點(diǎn),因?yàn)槲业睦斫庖呀?jīng)改變。我現(xiàn)在相信這是可能的var
若要影響在方法返回接口的情況下的性能,但您應(yīng)該使用精確的類型。例如,如果您有此方法:
IList<int> Foo(){
return Enumerable.Range(0,10).ToList();}
考慮這三行代碼來(lái)調(diào)用該方法:
List<int> bar1 = Foo();IList<int> bar = Foo();var bar3 = Foo();
這三個(gè)編譯和執(zhí)行都是預(yù)期的。但是,前兩行是不完全相同,第三行將匹配第二行,而不是第一行。因?yàn)?的簽名Foo()
是返回一個(gè)IList<int>
,這就是編譯器將如何構(gòu)建bar3
變量。
從性能的角度來(lái)看,大多數(shù)情況下你不會(huì)注意到。然而,在某些情況下第三行的性能可能不如第一行的速度快。..當(dāng)您繼續(xù)使用bar3
變量時(shí),編譯器可能無(wú)法以相同的方式分派方法調(diào)用。
請(qǐng)注意,抖動(dòng)可能(可能甚至)能夠消除這種差異,但這并不一定。一般來(lái)說(shuō),你還是應(yīng)該考慮var
在性能上是一個(gè)非因素。當(dāng)然一點(diǎn)也不像使用dynamic
變量。但是說(shuō)它一點(diǎn)也不重要,這可能是夸大了它。