在上一篇文章中，我們通過一些示例談?wù)摿薎L與CLR中的一些特性。IL與C#等高級(jí)語(yǔ)言的作用類似，主要用于表示程序的邏輯。由于它同樣了解太多CLR中的高級(jí)特性，因此它在大部分情況下依舊無法展現(xiàn)出比那些高級(jí)語(yǔ)言更多的CLR細(xì)節(jié)。因此，如果您想要通過學(xué)習(xí)IL來了解CLR，那么這個(gè)過程很可能會(huì)“事倍功半”。因此，從這個(gè)角度來說，老趙并不傾向于學(xué)習(xí)IL。不過嚴(yán)格說來，即使IL無法看出CLR的細(xì)節(jié)，也不足以說明“IL無用”——這里說“無用”自然有些夸張。但是，如果我們還發(fā)現(xiàn)，那些原本被認(rèn)為需要通過IL挖掘到的東西，現(xiàn)在都可以使用更好的方法來獲得，并且可以起到“事半功倍”的效果，那么似乎我們真的沒有太多理由去追逐IL了。

　　在這篇文章中，我們使用最多的工具便是.NET Reflector，從.NET 1.x開始，.NET Reflector就是一個(gè)探究.NET框架（主要是BCL）內(nèi)部實(shí)現(xiàn)的有力工具，它可以把一個(gè)程序集高度還原成C#等高級(jí)語(yǔ)言的代碼。在它的幫助下，幾乎所有程序集實(shí)現(xiàn)都變得一目了然，這大大方便了我們的工作。老趙對(duì)此深有感觸，因?yàn)樵谀扯尾凰愣痰臅r(shí)間內(nèi)，我使用.NET Reflector閱讀過的代碼數(shù)量遠(yuǎn)遠(yuǎn)超過了自己編寫的代碼。與此相反的是，老趙幾乎沒有使用IL探索過.NET框架下的任何問題。這可能還涉及到方式方法和個(gè)人做事方式，但是如果這真有效果的話，為什么要舍近求遠(yuǎn)呢？希望您看過了這篇文章，也可以像我一樣擺脫IL，投入.NET Reflector的懷抱。

示例一：探究語(yǔ)言細(xì)節(jié)

　　C#語(yǔ)言從1.0到3.0版本的進(jìn)化過程中，大部分新特性都是依靠編譯器的魔法。就拿C#3.0的各種新特性來說，Lambda表達(dá)式，LINQ，自動(dòng)屬性等等，完全都是基于CLR 2.0中已有的功能，再配合新的C#編譯器而產(chǎn)生的各種神奇效果。有些朋友認(rèn)為，掌握IL之后便把握了.NET的根本，以不變應(yīng)萬變，只要讀懂IL，那么這些新特性都不會(huì)對(duì)您形成困擾。這話說的并沒有錯(cuò)，只是老趙認(rèn)為，“掌握IL”在這里只是一個(gè)“充分條件”而不是一個(gè)“必要條件”，我們完全可以使用.NET Reflector將程序集反編譯成C#代碼來觀察這些。

　　這里我們使用.NET Reflector來觀察最最常見，最最普通的foreach關(guān)鍵字的功能。我們都知道foreach是遍歷一個(gè)IEnumerble對(duì)象內(nèi)元素的方式，我們也都知道foreach其實(shí)是GoF Iterator模式的實(shí)現(xiàn)，通過MoveNext方法和Current屬性進(jìn)行配合共同完成。不過大部分朋友似乎都是從IL進(jìn)行觀察，或是“聽別人說”而了解這些的。事實(shí)上，.NET Reflector也可以很容易地證實(shí)這一點(diǎn)，只是這中間還有些“特別”的地方。那么首先，我們還是來準(zhǔn)備一個(gè)最簡(jiǎn)單的foreach語(yǔ)句：

static void DoEnumerable(IEnumerable<int> source) {foreach (int i in source){Console.WriteLine(i);} }

　　如果觀察它的IL代碼，即使不了解IL的朋友也一定可以看出，其中涉及到了GetEnumerator，MoveNext和Current等成員的訪問：

.method private hidebysig static void DoEnumerable(class [mscorlib]System.Collections.Generic.IEnumerable`1 source) cil managed {.maxstack 1.locals init ([0] int32 i,[1] class [mscorlib]System.Collections.Generic.IEnumerator`1 CS$5$0000)L_0000: ldarg.0 L_0001: callvirt instance class [mscorlib]System.Collections.Generic.IEnumerator`1[mscorlib]System.Collections.Generic.IEnumerable`1::GetEnumerator()L_0006: stloc.1 L_0007: br.s L_0016L_0009: ldloc.1 L_000a: callvirt instance !0 [mscorlib]System.Collections.Generic.IEnumerator`1::get_Current()L_000f: stloc.0 L_0010: ldloc.0 L_0011: call void [mscorlib]System.Console::WriteLine(int32)L_0016: ldloc.1 L_0017: callvirt instance bool [mscorlib]System.Collections.IEnumerator::MoveNext()L_001c: brtrue.s L_0009L_001e: leave.s L_002aL_0020: ldloc.1 L_0021: brfalse.s L_0029L_0023: ldloc.1 L_0024: callvirt instance void [mscorlib]System.IDisposable::Dispose()L_0029: endfinally L_002a: ret .try L_0007 to L_0020 finally handler L_0020 to L_002a }

　　但是，如果使用.NET Reflector觀察它的C#代碼又會(huì)如何呢？

private static void DoEnumerable(IEnumerable source) {foreach (int i in source){Console.WriteLine(i);} }

　　請(qǐng)注意，以上這段是由.NET Reflector從IL反編譯后得到的C#代碼，這簡(jiǎn)直……不是簡(jiǎn)直，是完完全全真真正正地和我們剛才寫的代碼一模一樣！這就是.NET Reflector的強(qiáng)大之處，由于它意識(shí)到IL調(diào)用了IEnumerable.GetEnumerator方法，因此它就“留心”判斷這個(gè)調(diào)用的“模式”是否符合一個(gè)標(biāo)準(zhǔn)的foreach，如果是，那么就會(huì)顯示為一個(gè)foreach語(yǔ)句而不是while...MoveNext。不過，這難道不就掩蓋了“事物本質(zhì)”了嗎？要知道我們的目標(biāo)可是探究foreach的形式，既然.NET Reflector幫不了的話，我們不還是需要去觀察IL嗎？

　　剛才老趙提到，.NET Reflector在判斷IL代碼時(shí)發(fā)現(xiàn)一些標(biāo)準(zhǔn)的模式時(shí)會(huì)進(jìn)行代碼“優(yōu)化”。那么我們能否讓.NET Reflector不要做這種“優(yōu)化”呢？答案是肯定的，只是需要您在.NET Reflector中進(jìn)行一些簡(jiǎn)單的設(shè)置：

　　打開View菜單中的Options對(duì)話框，在左側(cè)Disassembler選項(xiàng)卡中修改Optimization級(jí)別，默認(rèn)很可能是.NET 3.5，而現(xiàn)在我們要將其修改為None。這么做會(huì)讓.NET Reflector最大程度地“直接”翻譯IL代碼，而不做一些額外優(yōu)化。將Optimization級(jí)別設(shè)為None以后，DoEnumerable方法的代碼就變?yōu)榱?#xff1a;

static void DoEnumerable(IEnumerable<int> source) {int num;IEnumerator<int> enumerator;enumerator = source.GetEnumerator(); Label_0007:try{goto Label_0016;Label_0009:num = enumerator.Current;Console.WriteLine(num);Label_0016:if (enumerator.MoveNext() != null){goto Label_0009;}goto Label_002A;}finally{Label_0020:if (enumerator == null){goto Label_0029;}enumerator.Dispose();Label_0029: ;} Label_002A:return; }

　　這是C#代碼嗎？為什么會(huì)有那么多的goto？為什么MoveNext方法返回的布爾值可以和null進(jìn)行比較？其實(shí)您把這段代碼復(fù)制粘貼后會(huì)發(fā)現(xiàn)，它能夠正常編譯通過，效果也和剛才的foreach語(yǔ)句完全一樣。這就是去除“優(yōu)化”的效果。老趙在上一篇文章中談到說：IL和C#一樣，都是用于表現(xiàn)程序邏輯。C#使用if...else、while、for等等豐富語(yǔ)法，而在IL中就會(huì)變成判斷+跳轉(zhuǎn)語(yǔ)句。上面的C#代碼便直接保留了IL的這個(gè)“特性”。不過還好，我們還是可以看出try...finally，可以看出MoveNext方法和Current屬性的訪問，可以看到程序使用Console.WriteLine輸出數(shù)據(jù)。至此，我們便發(fā)現(xiàn)了foreach語(yǔ)句的真面目。從現(xiàn)在開始，在您準(zhǔn)備深入IL之前，老趙也建議您可以嘗試一下使用None Optimization來觀察C#代碼。

　　實(shí)事求是地說，上面的C#代碼的“轉(zhuǎn)向邏輯”并不那么清晰，因此您在理解的時(shí)候可以把它復(fù)制到編輯器中，進(jìn)行一些簡(jiǎn)單調(diào)整。但是從老趙的經(jīng)驗(yàn)上來看，需要使用None Optimization進(jìn)行探索的地方非常少見。foreach是一個(gè)，還有便是C#中的其他一些“別名”，如使用using關(guān)鍵字管理IDisposable對(duì)象，以及l(fā)ock關(guān)鍵字。而且，其實(shí)這段邏輯也只是沒有優(yōu)化IL中的跳轉(zhuǎn)語(yǔ)句而已，已經(jīng)比IL本身要直觀許多了。此外，關(guān)于對(duì)象創(chuàng)建，變量聲明，方法調(diào)用，屬性訪問，事件加載……一切的一切都還是最常用的C#代碼。因?yàn)檫€是那個(gè)原因：從大部分情況上來看，IL也只是表現(xiàn)了程序邏輯，并沒有比C#等語(yǔ)言體現(xiàn)出更多的細(xì)節(jié)。

　　我在這里舉了一個(gè)較為極端的例子，因?yàn)槲野l(fā)現(xiàn)不少朋友并沒有嘗試過使用None Optimization來觀察過代碼。這里也可以看出，.NET Reflector的“優(yōu)化級(jí)別”還不夠“細(xì)致”。不過這應(yīng)該是一個(gè)“產(chǎn)品設(shè)計(jì)”的正常結(jié)果，因?yàn)閒oreach/using/lock的關(guān)鍵字都是從.NET 1.0誕生伊始就存在的，也就是說，即使.NET Reflector選擇將IL編譯為C# 1.0，它的表現(xiàn)形式依舊是“標(biāo)準(zhǔn)模式”，這方面可能就不能過于強(qiáng)求了吧。至于其他一些探索，例如C#中的自動(dòng)屬性，Lambda表達(dá)式構(gòu)建表達(dá)式樹或匿名委托，乃至C# 4.0中的dynamic關(guān)鍵字，都是使用.NET 3.5 Optimization進(jìn)行探索便可得知的結(jié)果。您可以回憶一下自己看過的文章，其中有多少是使用IL解釋問題的呢？

示例二：學(xué)習(xí).NET平臺(tái)上的其他語(yǔ)言

　　在.NET平臺(tái)上，任何語(yǔ)言都會(huì)先編譯為IL，然后再運(yùn)行時(shí)由JIT轉(zhuǎn)化為機(jī)器碼。因此有種說法是，只要把握了IL，.NET平臺(tái)上各種語(yǔ)言之間的遷移都會(huì)變得容易。對(duì)此老趙有不同看法。在以前討論語(yǔ)言是否重要的時(shí)候，老趙提到，語(yǔ)言它并不僅僅是一種文字表現(xiàn)形式，而是一種“思維方式”的改變，這可能會(huì)影響到您程序的編碼風(fēng)格，API設(shè)計(jì)乃至架構(gòu)（這個(gè)鏈接可能打不開，因?yàn)椤?#xff09;。實(shí)際上，如果您只是在C#與VB.NET之間進(jìn)行遷移，原本就是一件相當(dāng)容易的事情，因?yàn)樗鼈冎g“語(yǔ)言”的各種概念和特性都非常接近。而一種改變您思維的語(yǔ)言，才是真正有價(jià)值，而且值得進(jìn)行比較和探索的。如果一味地追求“把握本源”，那么甚至還有比IL更低抽象的事務(wù)，但這些就已經(jīng)違背了“創(chuàng)造一門語(yǔ)言”，以及您學(xué)習(xí)它的目的了，不是嗎？

　　當(dāng)然，探索也是需要的，尤其是.NET平臺(tái)上的各種語(yǔ)言，他們被統(tǒng)一在同樣的平臺(tái)上，這本身就是一種很好的資源。這種資源就是所謂的“比較學(xué)習(xí)”。您可以把新的語(yǔ)言和您熟悉的語(yǔ)言進(jìn)行對(duì)比，吸收其中的長(zhǎng)處（如優(yōu)秀的思維方式），這樣便可以更好地使用舊有語(yǔ)言。例如，您把F#類庫(kù)轉(zhuǎn)化為C#代碼進(jìn)行觀察之后，發(fā)現(xiàn)其中大量函數(shù)式編程風(fēng)格的API是使用“委托”來實(shí)現(xiàn)的，您可能就會(huì)想到是否可以設(shè)計(jì)出函數(shù)式編程風(fēng)格的C# API，是否可以把F#中List或Seq模塊中的各種高階函數(shù)移植到您自己的項(xiàng)目中來。這就有了更好的價(jià)值，這價(jià)值也不僅僅只是您“學(xué)會(huì)了新的語(yǔ)言”。

　　例如，我們現(xiàn)在使用尾遞歸來計(jì)算斐波那契數(shù)列。在之前的文章中，我們的作法是：

private static int FibTail(int n, int acc1, int acc2) {if (n == 0) return acc1;return FibTail(n - 1, acc2, acc1 + acc2); } public static int Fib(int n) {return FibTail(n, 0, 1); }

　　為了“尾遞歸”，我們必須定義一個(gè)私有的FibTail方法，接收三個(gè)參數(shù)。而對(duì)外的接口還是一個(gè)公有的Fib方法，它返回斐波那契數(shù)列第n項(xiàng)的結(jié)果。這個(gè)示例很簡(jiǎn)單，作法也沒有任何問題。但是老趙有時(shí)候會(huì)覺得，我們?yōu)槭裁捶且x一個(gè)額外的“輔助方法”，然后在現(xiàn)有的方法里只是進(jìn)行一個(gè)簡(jiǎn)單的轉(zhuǎn)發(fā)？如果這個(gè)輔助方法會(huì)在其他地方得到調(diào)用也就罷了（我們遵守了DRY原則），但是現(xiàn)在卻有點(diǎn)“平白無故”地在代碼里增加了一個(gè)方法，這樣在VS的Class View或編輯器上方的下拉列表中也會(huì)多出一項(xiàng)。此外，為了表示兩個(gè)方法的關(guān)系，您可能還會(huì)使用region把它們包裹起來……

　　不過在F#中，上面的尾遞歸就可以這樣寫：

let fib n =let rec fibTail x acc1 acc2 =match x with| 0 -> acc1;| _ -> fibTail (x - 1) acc2 (acc1 + acc2)fibTail n 0 1

　　在fib方法內(nèi)部，我們可以重新定義一個(gè)fibTail方法，其中實(shí)現(xiàn)了尾遞歸。對(duì)于外部來說，只有fib方法是公開的，外界絲毫不知道fibTail方法的存在，這種定義內(nèi)部函數(shù)的作法在F#中非常常見。而編譯后，我們?cè)?NET Reflector中便可看到與之對(duì)應(yīng)的C#實(shí)現(xiàn)：

public static int fib(int n) {switch (n){case 0:return 0;}return fibTail@7@7(n - 1, 1, 1); } internal static int fibTail@7@7(int x, int acc1, int acc2) {... }

　　在F#中沒有internal的訪問級(jí)別，您可以認(rèn)為這里internal便是private。于是我們得知（可能您本身也猜得到）：由于.NET本身并沒有“嵌套方法”特性，因此在這里編譯器會(huì)重新生成一個(gè)特殊的私有方法，并且在fib方法里進(jìn)行調(diào)用。于是我們想到，這個(gè)“自動(dòng)生成方法”的特性，在C#中也有體現(xiàn)啊。例如，IEnmuerable有一個(gè)擴(kuò)展方法是Where，我們可以用Lambda表達(dá)式構(gòu)造一個(gè)匿名委托作為參數(shù)……唔唔，這不就相當(dāng)于把一個(gè)方法定義在另一個(gè)方法內(nèi)部了嗎？于是，我們修改一下之前C#的尾遞歸的實(shí)現(xiàn)：

public static int Fib(int n) {Func<int, int, int, int> fibTail = null;fibTail = (x, acc1, acc2) =>{if (x == 0) return acc1;return fibTail(x - 1, acc2, acc1 + acc2);};return fibTail(n, 0, 1); }

　　如果沒有F#的“提示”，可能我們只能想到list.Where(i => i % 2 == 0)這種形式的用法，我們平時(shí)不會(huì)在方法內(nèi)部額外地“創(chuàng)建一個(gè)委托”，然后加以調(diào)用，而且還用到了“遞歸”——甚至還是“尾遞歸”（雖然C#編譯器在這里沒有進(jìn)行優(yōu)化，而且這里其實(shí)也只是個(gè)“偽遞歸”，因?yàn)閒ibTail其實(shí)是個(gè)可改變的“函數(shù)指針”）。不過，由于我們剛才通過C#來觀察F#的編譯結(jié)果，聯(lián)想到它和我們以前觀察到的C#中“某個(gè)特性”非常相似，再加上合理的嘗試，最終同樣得出了一個(gè)還算“令人滿意”的使用方式。

　　這只是一個(gè)示例，我并不是說這種作法是所謂的“最佳實(shí)踐”。任何辦法一旦遭到濫用也肯定不會(huì)有好處，您要根據(jù)當(dāng)前情況判斷是否應(yīng)該采取某種作法。剛才的演示只是為了說明，我們應(yīng)該如何從其他語(yǔ)言中吸取優(yōu)勢(shì)思想，改進(jìn)我們的編程工作。當(dāng)然，您使用IL來探索新的語(yǔ)言也沒有太大問題，C#能看到的東西用IL也可以看到。但是請(qǐng)您回想一下，即使您平時(shí)學(xué)習(xí)IL，您想過直接使用IL來寫程序嗎？您學(xué)習(xí)和探索新語(yǔ)言的目的，只是為了搞清楚它的IL表現(xiàn)形式嗎？為什么您不使用簡(jiǎn)單易懂的C#，卻要糾纏于IL中那些紛繁復(fù)雜的指令呢？

示例三：性能相關(guān)

　　學(xué)習(xí)IL對(duì)寫出高性能的.NET程序有幫助嗎？

　　記得以前在學(xué)習(xí)“計(jì)算機(jī)系統(tǒng)概論”課程時(shí)，有一個(gè)實(shí)驗(yàn)就是為幾段C程序進(jìn)行優(yōu)化。當(dāng)時(shí)的手段可謂無所不用其極，例如內(nèi)聯(lián)一個(gè)子過程以避免call指令的消耗，或把一段C代碼使用匯編進(jìn)行替換等等。從結(jié)果上看，它們都能對(duì)性能有“明顯”的提高。不過，那些都是為了加深概念而進(jìn)行的練習(xí)，并不是說在現(xiàn)代程序中應(yīng)該使用這種方式進(jìn)行優(yōu)化。現(xiàn)在早已不是在“指令級(jí)別”進(jìn)行性能優(yōu)化的時(shí)期了，連操作系統(tǒng)內(nèi)核也只是在一些對(duì)性能要求非常高的地方，如內(nèi)存管理，線程調(diào)度中的細(xì)微方面使用匯編來編寫，其余部分也都是用C語(yǔ)言來完成。這并不是僅僅是因?yàn)椤翱删S護(hù)性”等考慮，也有部分原因是因?yàn)樵谀壳熬幾g技術(shù)的發(fā)展下，一些極端的做法已經(jīng)很難產(chǎn)生有效的優(yōu)化效果了（例如一般來說來，程序員寫出的C代碼的性能會(huì)優(yōu)于他寫的匯編代碼）。

　　此外，在您不知道JIT究竟作了什么事情的情況下，觀察IL這樣一種高度抽象的語(yǔ)言，您還是無法真正判斷出一個(gè)程序從微觀上的性能如何。不過這并不是說，現(xiàn)代程序不應(yīng)該“主動(dòng)”追究性能，而是說，現(xiàn)代程序在性能優(yōu)化問題上并非如此簡(jiǎn)單，它涉及到的東西會(huì)更多，需要更加合適的手段。例如，即使您內(nèi)聯(lián)了一個(gè)子過程，也只是減少了call指令的所帶來的消耗，但是這與這個(gè)子過程本身“一長(zhǎng)串”指令相比，所帶來的提高是微乎其微的。而如果您一旦破壞了Locality或造成了False Sharing，或造成了資源競(jìng)爭(zhēng)等等，這可能就會(huì)造成數(shù)倍甚至更多的性能損耗。換句話說，影響現(xiàn)代應(yīng)用程序的性能的因素大都是“宏觀”的，用通俗的話來說，一般都是“寫法”上造成的問題。

　　這也是為什么說“Make clean code fast”遠(yuǎn)比“Make fast code clean”來的容易，現(xiàn)代程序更注重的是“清晰”而并非是“性能”。因?yàn)槌绦蚯逦?#xff0c;更容易讓人發(fā)現(xiàn)性能瓶頸究竟在何處，可以進(jìn)行有針對(duì)性地優(yōu)化（即使是那種在極端性能要求下故意進(jìn)行的“丑陋”寫法，也是為了高性能而“丑陋”，而不是因?yàn)椤俺舐倍咝阅?#xff0c;分清這一點(diǎn)很重要）。換句話說，如果我們有一種更清晰地方式來查看同樣的程序?qū)崿F(xiàn)，不也降低了探索程序性能瓶頸的難度嗎？那么，同樣一段程序，您會(huì)通過C#進(jìn)行觀察，還是使用IL呢？

　　有朋友可能會(huì)說：即使無法把握J(rèn)IT對(duì)于IL的優(yōu)化，但是從IL中可以看出高級(jí)語(yǔ)言，如C#的編譯器的優(yōu)化效果啊。這話本沒有錯(cuò)，但問題還是在于，C#的編譯器優(yōu)化效果，是否在“反編譯”回來之后就無法觀察到了呢？“優(yōu)化過程”往往都是不可逆的，它會(huì)造成信息丟失，導(dǎo)致我們很難從“優(yōu)化結(jié)果”中看出“原始模樣”，這一點(diǎn)在上一篇文章中也有過論述。換句話說，我們通過C# => IL => C#這一系列“轉(zhuǎn)化”之后，幾乎都可以清楚地發(fā)現(xiàn)C#編譯器做過哪些優(yōu)化。這里還是使用經(jīng)典的foreach作為示例，您知道以下兩個(gè)方法的性能高低如何？

static void DoArray(int[] source) {foreach (int i in source){Console.WriteLine(i);} } static void DoEnumerable(IEnumerable<int> source) {foreach (int i in source){Console.WriteLine(i);} }

　　經(jīng)過了C#編譯器的優(yōu)化，再使用.NET Reflector查看IL反編譯成C#（None Optimization）的結(jié)果，就會(huì)發(fā)現(xiàn)它們變成了此般模樣：

private static void DoArray(int[] source) {int num;int[] numArray;int num2;numArray = source;num2 = 0;goto Label_0014; Label_0006:num = numArray[num2];Console.WriteLine(num);num2 += 1; Label_0014:if (num2 < ((int)numArray.Length)){goto Label_0006;}return; } private static void DoEnumerable(IEnumerable<int> source) {int num;IEnumerator<int> enumerator;enumerator = source.GetEnumerator(); Label_0007: try{goto Label_0016;Label_0009:num = enumerator.Current;Console.WriteLine(num);Label_0016:if (enumerator.MoveNext() != null){goto Label_0009;}goto Label_002A;}finally{Label_0020:if (enumerator == null){goto Label_0029;}enumerator.Dispose();Label_0029: ;} Label_002A:return; }

　　C#編譯器的優(yōu)化效果表露無遺：對(duì)于int數(shù)組的foreach其實(shí)是被轉(zhuǎn)化為類似于for的下標(biāo)訪問遍歷，而對(duì)于IEnumerable還是保持了foreach關(guān)鍵字中標(biāo)準(zhǔn)的“while...MoveNext”模式（如果您把Console.WriteLine語(yǔ)句去掉的話，就可以使用.NET 3.5 Optimization直接看出兩者的不同，您不妨一試）。由此看來，DoArray的性能會(huì)比后兩者要高。事實(shí)上，由于性能主要是由“實(shí)現(xiàn)方式”決定的，因此我們可以通過反編譯成C#代碼的方式來閱讀.NET框架中的大部分代碼，IL在這里起到的效果很小。例如在文章《泛型真的會(huì)降低性能嗎？》里，Teddy大牛就通過閱讀.NET代碼來發(fā)現(xiàn)數(shù)組的IEnumerable實(shí)現(xiàn)，為什么性能遠(yuǎn)低于IEnumerable。

　　不過，判斷兩者性能高低，最簡(jiǎn)單，也最直接的方式還是進(jìn)行性能測(cè)試。例如您可以使用CodeTimer來比較DoArray和DoEnumerable方法的性能，一目了然。

　　值得一提的是，如果要進(jìn)行性能優(yōu)化，需要做的事情有很多，而“閱讀代碼”在其中的重要性其實(shí)并不高，而且它也最容易誤入歧途的一種。“閱讀代碼”充其量是一種人工的“靜態(tài)分析”，而程序的運(yùn)行效果是“動(dòng)態(tài)”的。這篇文章解釋了為什么使用foreach對(duì)ArrayList進(jìn)行遍歷的性能會(huì)比List低，其中使用了Profiler來說明問題。Profiler能告訴我們很多難以觀察到的事情，例如在遍歷中究竟是ArrayList哪個(gè)方法消耗時(shí)間最長(zhǎng)。此外它還發(fā)現(xiàn)了ArrayList在遍歷時(shí)創(chuàng)建了大量的對(duì)象，這種對(duì)于內(nèi)存資源的消耗，幾乎不可能從一小段代碼中觀察得出。此外，不同環(huán)境下，同樣的代碼可能執(zhí)行效果會(huì)有不同。如果沒有Profiler，我們可能會(huì)選擇把一段執(zhí)行了100遍的代碼性能提升1秒鐘，卻不會(huì)把一段執(zhí)行100000遍的代碼性能提升100毫秒。性能優(yōu)化的關(guān)鍵是“有的放矢”，如果沒有Profiler幫我們指明道路，做到這一點(diǎn)相當(dāng)困難。

　　其實(shí)老趙對(duì)于性能方面說的這些，可以大致歸納為以下三點(diǎn)：

• 關(guān)注IL，對(duì)于從微觀角度觀察程序性能很難有太大幫助，因?yàn)槟茈y具體指出JIT對(duì)IL的編譯方式。
• 關(guān)注IL，對(duì)于從宏觀角度觀察程序性能同樣很難有太大幫助，因?yàn)樗谋硎瞿芰Σ粫?huì)比C#來的直觀清晰。
• 性能優(yōu)化，最關(guān)鍵的一點(diǎn)是使用Profiler來找出性能瓶頸，有的放矢。

　　所以，如果您問老趙：“學(xué)習(xí)IL，對(duì)寫出高性能的.NET程序有幫助嗎？”我會(huì)回答：“有，肯定有啊”。

　　但是，如果您問老趙：“我想寫出高性能的.NET程序，應(yīng)該學(xué)習(xí)IL嗎？”我會(huì)回答：“別，別學(xué)IL”。

總結(jié)

　　feilng在前文留下的一些評(píng)論，我認(rèn)為說得非常有道理：

IL只是在CLR的抽象級(jí)別上說明干什么，而不是怎么干……重要的是要清楚在現(xiàn)實(shí)條件下，需要進(jìn)入那個(gè)層次才能獲取足夠的信息，掌握接口的完整語(yǔ)義和潛在副作用。

　　IL的確比C#等高級(jí)語(yǔ)言來的所謂“底層”，但是很明顯，IL本身也是一種高級(jí)抽象。而即使是機(jī)器碼，它也可以說是基于CPU的抽象，CPU上如流水線，并行，內(nèi)存模型，Cache Lock等東西對(duì)于匯編/機(jī)器碼來說也可以說是一種“封裝”。從不同層次可以獲得不同信息，我們追求“底層”的目的肯定也不是“底層”這兩個(gè)字，而是一種收獲。了解自身需要什么，然后能夠選擇一個(gè)合理的層次進(jìn)入，并得到更好的收益，這本身也是一種能力。追求IL的做法，本身并沒有錯(cuò)，只是追求IL一定是當(dāng)前情況下的最優(yōu)選擇嗎？這是一個(gè)值得不斷討論的問題，我的這篇文章也只是表達(dá)了我個(gè)人對(duì)某些問題的看法。

?

《新程序員》：云原生和全面數(shù)字化實(shí)踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結(jié)

以上是生活随笔為你收集整理的艾伟：老赵谈IL（3）：IL可以看到的东西，其实大都也可以用C#来发现的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。