日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

【編者按】Roslyn編譯器的項目經(jīng)理 BillChiles寫了一篇文章《Essential Performance Facts and .NET Framework Tips》的文章，以下是博主寒江獨釣對這篇14頁的文章的提煉和思考。本文主要分析了.NET程序的性能優(yōu)化基本要領(lǐng)和大量的優(yōu)化建議，分別從值類型(如結(jié)構(gòu)體)和引用類型(如類)的區(qū)別和使用場景，字符串的操作，裝箱拆箱操作等，這些在CLR Via C# 這本書中有系統(tǒng)的描述和講解。

創(chuàng)新互聯(lián)網(wǎng)站建設(shè)由有經(jīng)驗的網(wǎng)站設(shè)計師、開發(fā)人員和項目經(jīng)理組成的專業(yè)建站團隊，負責(zé)網(wǎng)站視覺設(shè)計、用戶體驗優(yōu)化、交互設(shè)計和前端開發(fā)等方面的工作，以確保網(wǎng)站外觀精美、成都網(wǎng)站制作、做網(wǎng)站、外貿(mào)營銷網(wǎng)站建設(shè)易于使用并且具有良好的響應(yīng)性。

---

本文提供了一些性能優(yōu)化的建議，這些經(jīng)驗來自于使用托管代碼重寫C# 和 VB編譯器，并以編寫C# 編譯器中的一些真實場景作為例子來展示這些優(yōu)化經(jīng)驗。.NET 平臺開發(fā)應(yīng)用程序具有極高的生產(chǎn)力。.NET 平臺上強大安全的編程語言以及豐富的類庫，使得開發(fā)應(yīng)用變得卓有成效。但是能力越大責(zé)任越大。我們應(yīng)該使用.NET框架的強大能力，但同時如果我們需要處理大量的數(shù)據(jù)比如文件或者數(shù)據(jù)庫也需要準備對我們的代碼進行調(diào)優(yōu)。

為什么來自新的編譯器的性能優(yōu)化經(jīng)驗也適用于您的應(yīng)用程序

微軟使用托管代碼重寫了C#和Visual Basic的編譯器，并提供了一些列新的API來進行代碼建模和分析、開發(fā)編譯工具，使得Visual Studio具有更加豐富的代碼感知的編程體驗。重寫編譯器，并且在新的編譯器上開發(fā)Visual Studio的經(jīng)驗使得我們獲得了非常有用的性能優(yōu)化經(jīng)驗，這些經(jīng)驗也能用于大型的.NET應(yīng)用，或者一些需要處理大量數(shù)據(jù)的APP上。你不需要了解編譯器，也能夠從C#編譯器的例子中得出這些見解。

Visual Studio使用了編譯器的API來實現(xiàn)了強大的智能感知(Intellisense)功能，如代碼關(guān)鍵字著色，語法填充列表，錯誤波浪線提示，參數(shù)提示，代碼問題及修改建議等，這些功能深受開發(fā)者歡迎。Visual Studio在開發(fā)者輸入或者修改代碼的時候，會動態(tài)的編譯代碼來獲得對代碼的分析和提示。

當(dāng)用戶和App進行交互的時候，通常希望軟件具有好的響應(yīng)性。輸入或者執(zhí)行命令的時候，應(yīng)用程序界面不應(yīng)該被阻塞。幫助或者提示能夠迅速顯示出來或者當(dāng)用戶繼續(xù)輸入的時候停止提示?，F(xiàn)在的App應(yīng)該避免在執(zhí)行長時間計算的時候阻塞UI線程從而讓用戶感覺程序不夠流暢。

想了解更多關(guān)于新的編譯器的信息，可以訪問 .NET Compiler Platform ("Roslyn")

基本要領(lǐng)

在對.NET 進行性能調(diào)優(yōu)以及開發(fā)具有良好響應(yīng)性的應(yīng)用程序的時候，請考慮以下這些基本要領(lǐng)：

要領(lǐng)一:不要過早優(yōu)化

編寫代碼比想象中的要復(fù)雜的多，代碼需要維護，調(diào)試及優(yōu)化性能。 一個有經(jīng)驗的程序員，通常會對自然而然的提出解決問題的方法并編寫高效的代碼。 但是有時候也可能會陷入過早優(yōu)化代碼的問題中。比如，有時候使用一個簡單的數(shù)組就夠了，非要優(yōu)化成使用哈希表，有時候簡單的重新計算一下可以，非要使用復(fù)雜的可能導(dǎo)致內(nèi)存泄漏的緩存。發(fā)現(xiàn)問題時，應(yīng)該首先測試性能問題然后再分析代碼。

要領(lǐng)二:沒有評測，便是猜測

剖析和測量不會撒謊。測評可以顯示CPU是否滿負荷運轉(zhuǎn)或者是存在磁盤I/O阻塞。測評會告訴你應(yīng)用程序分配了什么樣的以及多大的內(nèi)存，以及是否CPU花費了很多時間在垃圾回收上。

應(yīng)該為關(guān)鍵的用戶體驗或者場景設(shè)置性能目標(biāo)，并且編寫測試來測量性能。通過使用科學(xué)的方法來分析性能不達標(biāo)的原因的步驟如下：使用測評報告來指導(dǎo)，假設(shè)可能出現(xiàn)的情況，并且編寫實驗代碼或者修改代碼來驗證我們的假設(shè)或者修正。如果我們設(shè)置了基本的性能指標(biāo)并且經(jīng)常測試，就能夠避免一些改變導(dǎo)致性能的回退(regression)，這樣就能夠避免我們浪費時間在一些不必要的改動中。

要領(lǐng)三:好工具很重要

好的工具能夠讓我們能夠快速的定位到影響性能的***因素(CPU，內(nèi)存，磁盤)并且能夠幫助我們定位產(chǎn)生這些瓶頸的代碼。微軟已經(jīng)發(fā)布了很多性能測試工具比如：Visual Studio Profiler, Windows Phone Analysis Tool, 以及 PerfView.

PerfView是一款免費且性能強大的工具，他主要關(guān)注影響性能的一些深層次的問題(磁盤 I/O，GC 事件，內(nèi)存)，后面會展示這方面的例子。我們能夠抓取性能相關(guān)的 Event Tracing for Windows(ETW)事件并能以應(yīng)用程序，進程，堆棧，線程的尺度查看這些信息。PerfView能夠展示應(yīng)用程序分配了多少，以及分配了何種內(nèi)存以及應(yīng)用程序中的函數(shù)以及調(diào)用堆棧對內(nèi)存分配的貢獻。這些方面的細節(jié)，您可以查看隨工具下載發(fā)布的關(guān)于PerfView的非常詳細的幫助，Demo以及視頻教程（比如Channel9 上的視頻教程）

要領(lǐng)四：所有的都與內(nèi)存分配相關(guān)

你可能會想，編寫響應(yīng)及時的基于.NET的應(yīng)用程序關(guān)鍵在于采用好的算法，比如使用快速排序替代冒泡排序，但是實際情況并不是這樣。編寫一個響應(yīng)良好的app的***因素在于內(nèi)存分配，特別是當(dāng)app非常大或者處理大量數(shù)據(jù)的時候。

在使用新的編譯器API開發(fā)響應(yīng)良好的IDE的實踐中，大部分工作都花在了如何避免開辟內(nèi)存以及管理緩存策略。PerfView追蹤顯示新的C# 和VB編譯器的性能基本上和CPU的性能瓶頸沒有關(guān)系。編譯器在讀入成百上千甚至上萬行代碼，讀入元數(shù)據(jù)活著產(chǎn)生編譯好的代碼，這些操作其實都是I/O bound 密集型。UI線程的延遲幾乎全部都是由于垃圾回收導(dǎo)致的。.NET框架對垃圾回收的性能已經(jīng)進行過高度優(yōu)化，他能夠在應(yīng)用程序代碼執(zhí)行的時候并行的執(zhí)行垃圾回收的大部分操作。但是，單個內(nèi)存分配操作有可能會觸發(fā)一次昂貴的垃圾回收操作，這樣GC會暫時掛起所有線程來進行垃圾回收(比如 Generation 2型的垃圾回收)

常見的內(nèi)存分配以及例子

這部分的例子雖然背后關(guān)于內(nèi)存分配的地方很少。但是，如果一個大的應(yīng)用程序執(zhí)行足夠多的這些小的會導(dǎo)致內(nèi)存分配的表達式，那么這些表達式會導(dǎo)致幾百M，甚至幾G的內(nèi)存分配。比如，在性能測試團隊把問題定位到輸入場景之前，一分鐘的測試模擬開發(fā)者在編譯器里面編寫代碼會分配幾G的內(nèi)存。

裝箱

裝箱發(fā)生在當(dāng)通常分配在線程棧上或者數(shù)據(jù)結(jié)構(gòu)中的值類型，或者臨時的值需要被包裝到對象中的時候（比如分配一個對象來存放數(shù)據(jù)，活著返回一個指針給一個Object對象）。.NET框架由于方法的簽名或者類型的分配位置，有些時候會自動對值類型進行裝箱。將值類型包裝為引用類型會產(chǎn)生內(nèi)存分配。.NET框架及語言會盡量避免不必要的裝箱，但是有時候在我們沒有注意到的時候會產(chǎn)生裝箱操作。過多的裝箱操作會在應(yīng)用程序中分配成M上G的內(nèi)存，這就意味著垃圾回收的更加頻繁，也會花更長時間。

在PerfView中查看裝箱操作，只需要開啟一個追蹤（trace），然后查看應(yīng)用程序名字下面的GC Heap Alloc 項（記住，PerfView會報告所有的進程的資源分配情況），如果在分配相中看到了一些諸如System.Int32和System.Char的值類型，那么就發(fā)生了裝箱。選擇一個類型，就會顯示調(diào)用棧以及發(fā)生裝箱的操作的函數(shù)。

例1 string方法和其值類型參數(shù)

下面的示例代碼演示了潛在的不必要的裝箱以及在大的系統(tǒng)中的頻繁的裝箱操作。

public class Logger
{
    public static void WriteLine(string s)
    {
        /*...*/
    }
}
public class BoxingExample
{
    public void Log(int id, int size)
    {
        var s = string.Format("{0}:{1}", id, size);
        Logger.WriteLine(s);
    }
}

這是一個日志基礎(chǔ)類，因此app會很頻繁的調(diào)用Log函數(shù)來記日志，可能該方法會被調(diào)用millons次。問題在于，調(diào)用string.Format方法會調(diào)用其重載的接受一個string類型和兩個Object類型的方法：

String.Format Method (String, Object, Object)

該重載方法要求.NET Framework 把int型裝箱為object類型然后將它傳到方法調(diào)用中去。為了解決這一問題，方法就是調(diào)用id.ToString()和size.ToString()方法，然后傳入到string.Format 方法中去，調(diào)用ToString()方法的確會導(dǎo)致一個string的分配，但是在string.Format方法內(nèi)部不論怎樣都會產(chǎn)生string類型的分配。

你可能會認為這個基本的調(diào)用string.Format 僅僅是字符串的拼接，所以你可能會寫出這樣的代碼：

var s = id.ToString() + ':' + size.ToString();

實際上，上面這行代碼也會導(dǎo)致裝箱，因為上面的語句在編譯的時候會調(diào)用：

string.Concat(Object, Object, Object);

這個方法，.NET Framework 必須對字符常量進行裝箱來調(diào)用Concat方法。

解決方法：

完全修復(fù)這個問題很簡單，將上面的單引號替換為雙引號即將字符常量換為字符串常量就可以避免裝箱，因為string類型的已經(jīng)是引用類型了。

var s = id.ToString() + ":" + size.ToString();

例2 枚舉類型的裝箱

下面的這個例子是導(dǎo)致新的C# 和VB編譯器由于頻繁的使用枚舉類型，特別是在Dictionary中做查找操作時分配了大量內(nèi)存的原因。

public enum Color { Red, Green, Blue }
public class BoxingExample
{
    private string name;
    private Color color;
    public override int GetHashCode()
    {
        return name.GetHashCode() ^ color.GetHashCode();
    }
}

問題非常隱蔽，PerfView會告訴你enmu.GetHashCode()由于內(nèi)部實現(xiàn)的原因產(chǎn)生了裝箱操作，該方法會在底層枚舉類型的表現(xiàn)形式上進行裝箱，如果仔細看PerfView，會看到每次調(diào)用GetHashCode會產(chǎn)生兩次裝箱操作。編譯器插入一次，.NET Framework插入另外一次。

解決方法：

通過在調(diào)用GetHashCode的時候?qū)⒚杜e的底層表現(xiàn)形式進行強制類型轉(zhuǎn)換就可以避免這一裝箱操作。

((int)color).GetHashCode()

另一個使用枚舉類型經(jīng)常產(chǎn)生裝箱的操作時enum.HasFlag。傳給HasFlag的參數(shù)必須進行裝箱，在大多數(shù)情況下，反復(fù)調(diào)用HasFlag通過位運算測試非常簡單和不需要分配內(nèi)存。

要牢記基本要領(lǐng)***條，不要過早優(yōu)化。并且不要過早的開始重寫所有代碼。 需要注意到這些裝箱的耗費，只有在通過工具找到并且定位到最主要問題所在再開始修改代碼。

字符串

字符串操作是引起內(nèi)存分配的***元兇之一，通常在PerfView中占到前五導(dǎo)致內(nèi)存分配的原因。應(yīng)用程序使用字符串來進行序列化，表示JSON和REST。在不支持枚舉類型的情況下，字符串可以用來與其他系統(tǒng)進行交互。當(dāng)我們定位到是由于string操作導(dǎo)致對性能產(chǎn)生嚴重影響的時候，需要留意string類的Format(),Concat(),Split(),Join(),Substring()等這些方法。使用StringBuilder能夠避免在拼接多個字符串時創(chuàng)建多個新字符串的開銷，但是StringBuilder的創(chuàng)建也需要進行良好的控制以避免可能會產(chǎn)生的性能瓶頸。

例3 字符串操作

在C#編譯器中有如下方法來輸出方法前面的xml格式的注釋。

public void WriteFormattedDocComment(string text)
{
    string[] lines = text.Split(new[] {"\r\n", "\r", "\n"},
        StringSplitOptions.None);
    int numLines = lines.Length;
    bool skipSpace = true;
    if (lines[0].TrimStart().StartsWith("http:///"))
    {
        for (int i = 0; i < numLines; i++)
        {
            string trimmed = lines[i].TrimStart();
            if (trimmed.Length < 4 || !char.IsWhiteSpace(trimmed[3]))
            {
                skipSpace = false;
                break;
            }
        }
        int substringStart = skipSpace ? 4 : 3;
        for (int i = 0; i < numLines; i++)
            Console.WriteLine(lines[i].TrimStart().Substring(substringStart));
    }
    else
    {
        /* ... */
    }
}

可以看到，在這片代碼中包含有很多字符串操作。代碼中使用類庫方法來將行分割為字符串，來去除空格，來檢查參數(shù)text是否是XML文檔格式的注釋，然后從行中取出字符串處理。

在WriteFormattedDocComment方法每次被調(diào)用時，***行代碼調(diào)用Split()就會分配三個元素的字符串?dāng)?shù)組。編譯器也需要產(chǎn)生代碼來分配這個數(shù)組。因為編譯器并不知道，如果Splite()存儲了這一數(shù)組，那么其他部分的代碼有可能會改變這個數(shù)組，這樣就會影響到后面對WriteFormattedDocComment方法的調(diào)用。每次調(diào)用Splite()方法也會為參數(shù)text分配一個string，然后在分配其他內(nèi)存來執(zhí)行splite操作。

WriteFormattedDocComment方法中調(diào)用了三次TrimStart()方法，在內(nèi)存環(huán)中調(diào)用了兩次，這些都是重復(fù)的工作和內(nèi)存分配。更糟糕的是，TrimStart()的無參重載方法的簽名如下：

namespace System
{ 
    public class String 
    { 
        public string TrimStart(params char[] trimChars);
    }
}

該方法簽名意味著，每次對TrimStart()的調(diào)用都回分配一個空的數(shù)組以及返回一個string類型的結(jié)果。

***，調(diào)用了一次Substring()方法，這個方法通常會導(dǎo)致在內(nèi)存中分配新的字符串。

解決方法：

和前面的只需要小小的修改即可解決內(nèi)存分配的問題不同。在這個例子中，我們需要從頭看，查看問題然后采用不同的方法解決。比如，可以意識到WriteFormattedDocComment()方法的參數(shù)是一個字符串，它包含了方法中需要的所有信息，因此，代碼只需要做更多的index操作，而不是分配那么多小的string片段。

下面的方法并沒有完全解，但是可以看到如何使用類似的技巧來解決本例中存在的問題。C#編譯器使用如下的方式來消除所有的額外內(nèi)存分配。

private int IndexOfFirstNonWhiteSpaceChar(string text, int start)
{
    while (start < text.Length && char.IsWhiteSpace(text[start])) 
        start++;
    return start;
}

private bool TrimmedStringStartsWith(string text, int start, string prefix)
{
    start = IndexOfFirstNonWhiteSpaceChar(text, start); 
    int len = text.Length - start; 
    if (len < prefix.Length) return false;
    for (int i = 0; i < len; i++)
    {
        if (prefix[i] != text[start + i]) 
            return false;
    }
    return true;
}

WriteFormattedDocComment() 方法的***個版本分配了一個數(shù)組，幾個子字符串，一個trim后的子字符串，以及一個空的params數(shù)組。也檢查了”///”。修改后的代碼僅使用了index操作，沒有任何額外的內(nèi)存分配。它查找***個非空格的字符串，然后逐個字符串比較來查看是否以”///”開頭。和使用TrimStart()不同，修改后的代碼使用IndexOfFirstNonWhiteSpaceChar方法來返回***個非空格的開始位置，通過使用這種方法，可以移除WriteFormattedDocComment()方法中的所有額外內(nèi)存分配。

例4 StringBuilder

本例中使用StringBuilder。下面的函數(shù)用來產(chǎn)生泛型類型的全名：

public class Example 
{ 
    // Constructs a name like "SomeType" 
    public string GenerateFullTypeName(string name, int arity) 
    { 
        StringBuilder sb = new StringBuilder();
        sb.Append(name);
        if (arity != 0)
        { 
            sb.Append("<");
            for (int i = 1; i < arity; i++)
            {
                sb.Append("T"); sb.Append(i.ToString()); sb.Append(", ");
            } 
            sb.Append("T"); sb.Append(i.ToString()); sb.Append(">");
        }
        return sb.ToString(); 
    }
}

注意力集中到StringBuilder實例的創(chuàng)建上來。代碼中調(diào)用sb.ToString()會導(dǎo)致一次內(nèi)存分配。在StringBuilder中的內(nèi)部實現(xiàn)也會導(dǎo)致內(nèi)部內(nèi)存分配，但是我們?nèi)绻胍@取到string類型的結(jié)果化，這些分配無法避免。

解決方法：

要解決StringBuilder對象的分配就使用緩存。即使緩存一個可能被隨時丟棄的單個實例對象也能夠顯著的提高程序性能。下面是該函數(shù)的新的實現(xiàn)。除了下面兩行代碼，其他代碼均相同

// Constructs a name like "Foo" 
public string GenerateFullTypeName(string name, int arity)
{
    StringBuilder sb = AcquireBuilder(); /* Use sb as before */ 
    return GetStringAndReleaseBuilder(sb);
}

關(guān)鍵部分在于新的 AcquireBuilder()和GetStringAndReleaseBuilder()方法：

[ThreadStatic]
private static StringBuilder cachedStringBuilder;

private static StringBuilder AcquireBuilder()
{
    StringBuilder result = cachedStringBuilder;
    if (result == null)
    {
        return new StringBuilder();
    } 
    result.Clear(); 
    cachedStringBuilder = null; 
    return result;
}

private static string GetStringAndReleaseBuilder(StringBuilder sb)
{
    string result = sb.ToString(); 
    cachedStringBuilder = sb; 
    return result;
}

上面方法實現(xiàn)中使用了thread-static字段來緩存StringBuilder對象，這是由于新的編譯器使用了多線程的原因。很可能會忘掉這個ThreadStatic聲明。Thread-static字符為每個執(zhí)行這部分的代碼的線程保留一個唯一的實例。

如果已經(jīng)有了一個實例，那么AcquireBuilder()方法直接返回該緩存的實例，在清空后，將該字段或者緩存設(shè)置為null。否則AcquireBuilder()創(chuàng)建一個新的實例并返回，然后將字段和cache設(shè)置為null 。

當(dāng)我們對StringBuilder處理完成之后，調(diào)用GetStringAndReleaseBuilder()方法即可獲取string結(jié)果。然后將StringBuilder保存到字段中或者緩存起來，然后返回結(jié)果。這段代碼很可能重復(fù)執(zhí)行，從而創(chuàng)建多個StringBuilder對象，雖然很少會發(fā)生。代碼中僅保存***被釋放的那個StringBuilder對象來留作后用。新的編譯器中，這種簡單的的緩存策略極大地減少了不必要的內(nèi)存分配。.NET Framework 和MSBuild 中的部分模塊也使用了類似的技術(shù)來提升性能。

簡單的緩存策略必須遵循良好的緩存設(shè)計，因為他有大小的限制cap。使用緩存可能比之前有更多的代碼，也需要更多的維護工作。我們只有在發(fā)現(xiàn)這是個問題之后才應(yīng)該采緩存策略。PerfView已經(jīng)顯示出StringBuilder對內(nèi)存的分配貢獻相當(dāng)大。

#p#

LINQ和Lambdas表達式

使用LINQ 和Lambdas表達式是C#語言強大生產(chǎn)力的一個很好體現(xiàn)，但是如果代碼需要執(zhí)行很多次的時候，可能需要對LINQ或者Lambdas表達式進行重寫。

例5 Lambdas表達式，List，以及IEnumerable

下面的例子使用LINQ以及函數(shù)式風(fēng)格的代碼來通過編譯器模型給定的名稱來查找符號。

class Symbol 
{ 
    public string Name { get; private set; } /*...*/
}
class Compiler 
{ 
    private List symbols; 
    public Symbol FindMatchingSymbol(string name) 
    { 
        return symbols.FirstOrDefault(s => s.Name == name); 
    }
}

新的編譯器和IDE 體驗基于調(diào)用FindMatchingSymbol，這個調(diào)用非常頻繁，在此過程中，這么簡單的一行代碼隱藏了基礎(chǔ)內(nèi)存分配開銷。為了展示這其中的分配，我們首先將該單行函數(shù)拆分為兩行：

Func predicate = s => s.Name == name; 
return symbols.FirstOrDefault(predicate);

***行中，lambda表達式 “s=>s.Name==name” 是對本地變量name的一個閉包。這就意味著需要分配額外的對象來為委托對象predict分配空間，需要一個分配一個靜態(tài)類來保存環(huán)境從而保存name的值。編譯器會產(chǎn)生如下代碼：

// Compiler-generated class to hold environment state for lambda 
private class Lambda1Environment 
{ 
    public string capturedName; 
    public bool Evaluate(Symbol s) 
    { 
        return s.Name == this.capturedName;
    } 
}

// Expanded Func predicate = s => s.Name == name; 
Lambda1Environment l = new Lambda1Environment() 
{ 
    capturedName = name
}; 
var predicate = new Func(l.Evaluate);

兩個new操作符（***個創(chuàng)建一個環(huán)境類，第二個用來創(chuàng)建委托）很明顯的表明了內(nèi)存分配的情況。

現(xiàn)在來看看FirstOrDefault方法的調(diào)用，他是IEnumerable類的擴展方法，這也會產(chǎn)生一次內(nèi)存分配。因為FirstOrDefault使用IEnumerable作為***個參數(shù)，可以將上面的展開為下面的代碼：

// Expanded return symbols.FirstOrDefault(predicate) ... 
IEnumerable enumerable = symbols;
IEnumerator enumerator = enumerable.GetEnumerator(); 
while (enumerator.MoveNext())
{ 
    if (predicate(enumerator.Current)) 
        return enumerator.Current; 
} 
return default(Symbol);

symbols變量是類型為List的變量。List集合類型實現(xiàn)了IEnumerable即可并且清晰地定義了一個迭代器，List的迭代器使用了一種結(jié)構(gòu)體來實現(xiàn)。使用結(jié)構(gòu)而不是類意味著通?？梢员苊馊魏卧谕泄芏焉系姆峙?，從而可以影響垃圾回收的效率。枚舉典型的用處在于方便語言層面上使用foreach循環(huán)，他使用enumerator結(jié)構(gòu)體在調(diào)用推棧上返回。遞增調(diào)用堆棧指針來為對象分配空間，不會影響GC對托管對象的操作。

在上面的展開FirstOrDefault調(diào)用的例子中，代碼會調(diào)用IEnumerabole接口中的GetEnumerator()方法。將symbols賦值給IEnumerable類型的enumerable 變量，會使得對象丟失了其實際的List類型信息。這就意味著當(dāng)代碼通過enumerable.GetEnumerator()方法獲取迭代器時，.NET Framework 必須對返回的值（即迭代器，使用結(jié)構(gòu)體實現(xiàn)）類型進行裝箱從而將其賦給IEnumerable類型的(引用類型) enumerator變量。

解決方法：

解決辦法是重寫FindMatchingSymbol方法，將單個語句使用六行代碼替代，這些代碼依舊連貫，易于閱讀和理解，也很容易實現(xiàn)。

public Symbol FindMatchingSymbol(string name) 
{ 
    foreach (Symbol s in symbols)
    { 
        if (s.Name == name) 
            return s; 
    } 
    return null; 
}

代碼中并沒有使用LINQ擴展方法，lambdas表達式和迭代器，并且沒有額外的內(nèi)存分配開銷。這是因為編譯器看到symbol 是List類型的集合，因為能夠直接將返回的結(jié)構(gòu)性的枚舉器綁定到類型正確的本地變量上，從而避免了對struct類型的裝箱操作。原先的代碼展示了C#語言豐富的表現(xiàn)形式以及.NET Framework 強大的生產(chǎn)力。該著后的代碼則更加高效簡單，并沒有添加復(fù)雜的代碼而增加可維護性。

Aync異步

接下來的例子展示了當(dāng)我們試圖緩存一部方法返回值時的一個普遍問題：

例6 緩存異步方法

Visual Studio IDE 的特性在很大程度上建立在新的C#和VB編譯器獲取語法樹的基礎(chǔ)上，當(dāng)編譯器使用async的時候仍能夠保持Visual Stuido能夠響應(yīng)。下面是獲取語法樹的***個版本的代碼：

class Parser 
{
    /*...*/ 
    public SyntaxTree Syntax
    { 
        get; 
    } 
    
    public Task ParseSourceCode() 
    {
        /*...*/ 
    } 
}
class Compilation 
{ 
    /*...*/ 
    public async Task GetSyntaxTreeAsync() 
    { 
        var parser = new Parser(); // allocation 
        await parser.ParseSourceCode(); // expensive 
        return parser.Syntax;
    } 
}

可以看到調(diào)用GetSyntaxTreeAsync() 方法會實例化一個Parser對象，解析代碼，然后返回一個Task對象。最耗性能的地方在為Parser實例分配內(nèi)存并解析代碼。方法中返回一個Task對象，因此調(diào)用者可以await解析工作，然后釋放UI線程使得可以響應(yīng)用戶的輸入。

由于Visual Studio的一些特性可能需要多次獲取相同的語法樹， 所以通?？赡軙彺娼馕鼋Y(jié)果來節(jié)省時間和內(nèi)存分配，但是下面的代碼可能會導(dǎo)致內(nèi)存分配：

class Compilation 
{ /*...*/
    private SyntaxTree cachedResult;
    public async Task GetSyntaxTreeAsync() 
    { 
        if (this.cachedResult == null) 
        { 
            var parser = new Parser(); // allocation 
            await parser.ParseSourceCode(); // expensive 
            this.cachedResult = parser.Syntax; 
        } 
        return this.cachedResult;
    }
}

代碼中有一個SynataxTree類型的名為cachedResult的字段。當(dāng)該字段為空的時候，GetSyntaxTreeAsync()執(zhí)行，然后將結(jié)果保存在cache中。GetSyntaxTreeAsync()方法返回SyntaxTree對象。問題在于，當(dāng)有一個類型為Task 類型的async異步方法時，想要返回SyntaxTree的值，編譯器會生出代碼來分配一個Task來保存執(zhí)行結(jié)果（通過使用Task.FromResult()）。Task會標(biāo)記為完成，然后結(jié)果立馬返回。分配Task對象來存儲執(zhí)行的結(jié)果這個動作調(diào)用非常頻繁，因此修復(fù)該分配問題能夠極大提高應(yīng)用程序響應(yīng)性。

解決方法：

要移除保存完成了執(zhí)行任務(wù)的分配，可以緩存Task對象來保存完成的結(jié)果。

class Compilation 
{ /*...*/
    private Task cachedResult;
    public Task GetSyntaxTreeAsync() 
    { 
        return this.cachedResult ?? (this.cachedResult = GetSyntaxTreeUncachedAsync()); 
    }
    private async Task GetSyntaxTreeUncachedAsync() 
    {
        var parser = new Parser(); // allocation 
        await parser.ParseSourceCode(); // expensive 
        return parser.Syntax; 
    } 
}

代碼將cachedResult 類型改為了Task 并且引入了async幫助函數(shù)來保存原始代碼中的GetSyntaxTreeAsync()函數(shù)。GetSyntaxTreeAsync函數(shù)現(xiàn)在使用 null操作符，來表示當(dāng)cachedResult不為空時直接返回，為空時GetSyntaxTreeAsync調(diào)用GetSyntaxTreeUncachedAsync()然后緩存結(jié)果。注意GetSyntaxTreeAsync并沒有await調(diào)用GetSyntaxTreeUncachedAsync。沒有使用await意味著當(dāng)GetSyntaxTreeUncachedAsync返回Task類型時，GetSyntaxTreeAsync 也立即返回Task， 現(xiàn)在緩存的是Task，因此在返回緩存結(jié)果的時候沒有額外的內(nèi)存分配。

其他一些影響性能的雜項

在大的app或者處理大量數(shù)據(jù)的app中，還有幾點可能會引發(fā)潛在的性能問題。

字典

在很多應(yīng)用程序中，Dictionary用的很廣，雖然字非常方便和高校，但是經(jīng)常會使用不當(dāng)。在Visual Studio以及新的編譯器中，使用性能分析工具發(fā)現(xiàn)，許多dictionay只包含有一個元素或者干脆是空的。一個空的Dictionay結(jié)構(gòu)內(nèi)部會有10個字段在x86機器上的托管堆上會占據(jù)48個字節(jié)。當(dāng)需要在做映射或者關(guān)聯(lián)數(shù)據(jù)結(jié)構(gòu)需要事先常量時間查找的時候，字典非常有用。但是當(dāng)只有幾個元素，使用字典就會浪費大量內(nèi)存空間。相反，我們可以使用List>結(jié)構(gòu)來實現(xiàn)便利，對于少量元素來說，同樣高校。如果僅僅使用字典來加載數(shù)據(jù)，然后讀取數(shù)據(jù)，那么使用一個具有N（log(N)）的查找效率的有序數(shù)組，在速度上也會很快，當(dāng)然這些都取決于的元素的個數(shù)。

類和結(jié)構(gòu)

不甚嚴格的講，在優(yōu)化應(yīng)用程序方面，類和結(jié)構(gòu)提供了一種經(jīng)典的空間/時間的權(quán)衡(trade off)。在x86機器上，每個類即使沒有任何字段，也會分配12 byte的空間 (譯注：來保存類型對象指針和同步索引塊)，但是將類作為方法之間參數(shù)傳遞的時候卻十分高效廉價，因為只需要傳遞指向類型實例的指針即可。結(jié)構(gòu)體如果不撞向的話，不會再托管堆上產(chǎn)生任何內(nèi)存分配，但是當(dāng)將一個比較大的結(jié)構(gòu)體作為方法參數(shù)或者返回值得時候，需要CPU時間來自動復(fù)制和拷貝結(jié)構(gòu)體，然后將結(jié)構(gòu)體的屬性緩存到本地便兩種以避免過多的數(shù)據(jù)拷貝。

緩存

性能優(yōu)化的一個常用技巧是緩存結(jié)果。但是如果緩存沒有大小上限或者良好的資源釋放機制就會導(dǎo)致內(nèi)存泄漏。在處理大數(shù)據(jù)量的時候，如果在緩存中緩存了過多數(shù)據(jù)就會占用大量內(nèi)存，這樣導(dǎo)致的垃圾回收開銷就會超過在緩存中查找結(jié)果所帶來的好處。

結(jié)論

在大的系統(tǒng)，或者或者需要處理大量數(shù)據(jù)的系統(tǒng)中，我們需要關(guān)注產(chǎn)生性能瓶頸癥狀，這些問題再規(guī)模上會影響app的響應(yīng)性，如裝箱操作、字符串操作、LINQ和Lambda表達式、緩存async方法、緩存缺少大小限制以及良好的資源釋放策略、使用Dictionay不當(dāng)、以及到處傳遞結(jié)構(gòu)體等。在優(yōu)化我們的應(yīng)用程序的時候，需要時刻注意之前提到過的四點：

1. 不要進行過早優(yōu)化——在定位和發(fā)現(xiàn)問題之后再進行調(diào)優(yōu)。
2. 專業(yè)測試不會說謊——沒有評測，便是猜測。
3. 好工具很重要?！螺dPerfView，然后去看使用教程。
4. 內(nèi)存分配決定app的響應(yīng)性?！@也是新的編譯器性能團隊花的時間最多的地方。

參考資料

• 如果想觀看關(guān)于這一話題的演講，可以在Channel 9 上觀看。
• VS Profiler基礎(chǔ) http://msdn.microsoft.com/en-us/library/ms182372.aspx
• .NET 英語程序性能分析工具一覽 http://msdn.microsoft.com/en-us/library/hh156536.aspx
• Windows Phone性能分析工具http://msdn.microsoft.com/en-us/magazine/hh781024.aspx
• 一些C# 和VB性能優(yōu)化建議 http://msdn.microsoft.com/en-us/library/ms173196(v=vs.110).aspx (注:原文中該鏈接無內(nèi)容，連接地址應(yīng)該使http://msdn.microsoft.com/en-us/library/ms173196(v=vs.100).aspx )
• 一些高級優(yōu)化建議 http://curah.microsoft.com/4604/improving-your-net-apps-startup-performance

--------------------------------------------------------------------------

以上就是這篇文章的全部內(nèi)容，很多東西其實都很基礎(chǔ)，比如值類型(如結(jié)構(gòu)體)和引用類型(如類)的區(qū)別和使用場景，字符串的操作，裝箱拆箱操作等，這些在CLR Via C# 這本書中有系統(tǒng)的描述和講解。這里面特別需要強調(diào)的是很多時候我們并沒有意識到發(fā)生了裝箱操作，比如文中提到的枚舉類型獲取HashCode會導(dǎo)致裝箱，和這個相同的一個問題是，通常在我們將值類型作為Dictionay的key的時候，Dictionay在內(nèi)部實現(xiàn)會調(diào)用key的GetHashCode方法獲取哈希值進行散列，默認方法就會導(dǎo)致裝箱操作，之前面試的時候我也被問到過這個問題，在很早之前老趙寫過一篇 防止裝箱落實到底，只做一半也是失敗 就專門討論過這一問題，所以在寫代碼的時候需要格外注意。

微軟使用托管語言重寫了C# 和Visual Basic編譯器，并取得了比之前的編譯器更好的效果，更重要的是該編譯器已經(jīng)開源，VS的很多強大的功能正是建立在該編譯器的某些編譯和分析結(jié)果之上。這正是編譯器即服務(wù)的體現(xiàn)，即“傳統(tǒng)的編譯器像是一個黑盒，你在一端輸入代碼，而另一端便會生成.NET程序集或是對象代碼等等。而這個黑盒卻很神秘，你目前很難參與或理解它的工作?！爆F(xiàn)在編譯器開源了，我們可以直接利用其中間生成的一些分析結(jié)果來為實現(xiàn)一些功能，比如C# Interactive (有時也稱為REPL，即Read-Eval-Print-Loop)。厲害的話，可以重寫一個簡單的Visual Studio了。

文章的作者從使用托管語言編寫C# 和 Visual Baisc編譯器中的性能優(yōu)化實踐講解了性能優(yōu)化的一些思考和建議，在很多方面，比如StringBuilder分配開銷，async函數(shù)返回值的緩存，LINQ和Lambda表達式產(chǎn)生的額外內(nèi)存分配方面令人印象深刻。還有一個很重要的方面就是不要盲目的沒有根據(jù)的優(yōu)化，首先定位和查找到造成產(chǎn)生性能問題的原因點最重要，以前我也經(jīng)常使用CLR Profile, VS Profile以及dotTrace查看和分析應(yīng)用程序的性能，文中提到了的PerfView工具是微軟內(nèi)部.NET Runtime團隊使用的，能夠看到一般工具不能提供的信息，功能很強大，在Channel9 上有該工具如何使用的詳細介紹。后面會簡單介紹下該工具如何使用。

希望本文對您在優(yōu)化.NET 應(yīng)用程序的性能方面有所幫助。

文章出自： 寒江獨釣的博客

新聞標(biāo)題：.NET程序的性能要領(lǐng)和優(yōu)化建議
文章分享：http://www.5511xx.com/article/dpochgh.html