1.?過早的優(yōu)化是萬惡之源

1.1.?著名的計(jì)算機(jī)科學(xué)家高德納(Donald Knuth)的一句名言

1.2.?原話是：“對于約97%的微小優(yōu)化點(diǎn)，我們應(yīng)該忽略它們：過早的優(yōu)化是萬惡之源。而對于剩下的關(guān)鍵的3%，我們則不能放棄優(yōu)化的機(jī)會?！?/h3>

2.?過早優(yōu)化是提升自己的根源

2.1.?優(yōu)化就是解決問題，過早優(yōu)化創(chuàng)造了暫時(shí)沒有發(fā)現(xiàn)的、假想的問題來解決，就像國際象棋選手設(shè)置棋局來挑戰(zhàn)自己

2.2.?探索性編程是提高技能的合法途徑

3.?不要過早優(yōu)化的原因

3.1.?優(yōu)化會增加代碼的耦合性，使其更難維護(hù)

3.2.?優(yōu)化也是一項(xiàng)投資，其回報(bào)在很大程度上取決于你能將優(yōu)化結(jié)果保持多久

3.3.?如果規(guī)范發(fā)生變化，你所進(jìn)行的優(yōu)化可能會讓你陷入一個(gè)難以擺脫的困境

3.4.?你可能試圖為一個(gè)本來就不存在的問題進(jìn)行優(yōu)化，而使你的代碼變得不那么可靠

4.?解決該解決的問題

4.1.?你需要真正理解你在優(yōu)化時(shí)到底做了什么權(quán)衡，這意味著你必須把需要解決的問題了解透徹

4.2.?根據(jù)問題的性質(zhì)，解決方式可以發(fā)揮的效用和實(shí)現(xiàn)它需要花費(fèi)的時(shí)間可能有很大的不同

4.3.?基準(zhǔn)測試(benchmarking)

4.3.1.?比較性能指標(biāo)的行為

4.3.1.1.?只能給你一堆用于比較的數(shù)字

4.3.1.2.?不能告訴你代碼的運(yùn)行速度是快還是慢

4.3.1.3.?可以告訴你它們比其他一些代碼運(yùn)行得慢還是快

4.3.2.?無法幫助你確定造成性能問題的根本原因

4.3.3.?可以幫助你確定是否存在性能問題

4.3.4.?你應(yīng)該常常對你的那些代碼優(yōu)化進(jìn)行基準(zhǔn)測試，來看看你的優(yōu)化是否還有更進(jìn)一步的余地

4.3.5.?BenchmarkDotNet庫

4.3.5.1.?可以消除因測量誤差或者調(diào)用開銷產(chǎn)生的波動

4.3.5.2.?適用于微觀基準(zhǔn)測試

4.3.5.2.1.?適用于微觀基準(zhǔn)測試

4.3.5.3.?基準(zhǔn)測試并沒有試圖消除函數(shù)調(diào)用的開銷或for循環(huán)本身的開銷

4.3.6.?Math.DivRem()函數(shù)比普通的除法和求余操作能快多少

4.3.6.1.?C#

public class SampleBenchmarkSuite {[Params(1000)]　　?---　避免編譯器優(yōu)化public int A;[Params(35)]　　?---　public int B;[Benchmark]　　?---　用屬性標(biāo)記要進(jìn)行基準(zhǔn)測試的操作public int Manual() {int division = A / B;int remainder = A % B;return division + remainder;　　?---　我們將值返回，這樣編譯器就不會丟掉計(jì)算步驟}[Benchmark]　　?---　public int DivRem() {int division = Math.DivRem(A, B, out int remainder);return division + remainder;　　?---　}
}
using System;
using System.Diagnostics;
using BenchmarkDotNet.Running;
namespace SimpleBenchmarkRunner {public class Program {public static void Main(string[] args) {BenchmarkRunner.Run＜SampleBenchmarkSuite＞();}}
}

4.3.6.2.?Math.DivRem()的速度是分別進(jìn)行除法和求余操作的兩倍

4.3.6.3.?使用Stopwatch編寫自己的基準(zhǔn)測試程序

4.3.6.4.?C#

private const int iterations = 1_000_000_000;
private static void runBenchmarks() {var suite = new SampleBenchmarkSuite {A = 1000,B = 35};long manualTime = runBenchmark(() =＞ suite.Manual());long divRemTime = runBenchmark(() =＞ suite.DivRem());reportResult("Manual", manualTime);reportResult("DivRem", divRemTime);}
private static long runBenchmark(Func＜int＞ action) {var watch = Stopwatch.StartNew();for (int n = 0; n ＜ iterations; n++) {action();　　?---　我們在這里調(diào)用基準(zhǔn)測試代碼}watch.Stop();return watch.ElapsedMilliseconds;
}
private static void reportResult(string name, long milliseconds) {double nanoseconds = milliseconds * 1_000_000;Console.WriteLine("{0} = {1}ns / operation",name,nanoseconds / iterations);
}

4.3.6.5.?DivRem函數(shù)的運(yùn)行速度比除法和求余操作快，因?yàn)樗晦D(zhuǎn)換為需要更少周期的指令

4.4.?性能與響應(yīng)性

4.4.1.?關(guān)于緩慢的一般原則

4.4.1.1.?任何需要超過100毫秒的動作都會讓人感覺到延遲，而任何需要超過300毫秒的動作都被認(rèn)為是緩慢的，更不要說花整整1秒的動作

4.4.2.?性能并不總是與響應(yīng)性(responsiveness)有關(guān)

4.4.3.?任務(wù)是計(jì)算密集型(computationally intensive)的

4.4.3.1.?最快的計(jì)算方法是在工作完成之前不做其他事情

4.4.3.2.?與其以最快的速度進(jìn)行計(jì)算，不如騰出一些計(jì)算周期來顯示一個(gè)進(jìn)度條，也許可以計(jì)算出估計(jì)的剩余時(shí)間，并在用戶等待的時(shí)候顯示一個(gè)漂亮的動畫

4.4.3.3.?最后，你的代碼運(yùn)行速度會變慢，但結(jié)果會更成功

4.4.4.?延遲也會影響性能，而不僅僅是用戶體驗(yàn)

4.4.4.1.?你的數(shù)據(jù)庫駐留在磁盤上，而你的數(shù)據(jù)庫服務(wù)器駐留在網(wǎng)絡(luò)上，這意味著，即使你寫了最快的SQL查詢，并在你的數(shù)據(jù)庫上定義了最快的索引，你仍然受到物理定律的約束，你不能得到任何快于1毫秒的結(jié)果

5.?遲緩的剖析

5.1.?并不是所有的性能問題都是關(guān)于速度的

5.1.1.?有些是關(guān)于響應(yīng)性的

5.2.?CPU是處理從RAM中讀取的指令的芯片，并在一個(gè)永無止境的循環(huán)中重復(fù)執(zhí)行這些指令

5.3.?時(shí)鐘周期(clock cycle)

5.3.1.?簡稱為周期

5.4.?CPU速度通常以赫茲(Hz)為單位，表示它在1秒內(nèi)能處理多少個(gè)時(shí)鐘周期

5.5.?有時(shí)CPU甚至可以處理比其處理速度所允許的更多指令

5.5.1.?一些指令需要一個(gè)以上的時(shí)鐘周期來完成

5.5.2.?現(xiàn)代CPU可以在一個(gè)核心上并行處理多條指令

5.6.?每一個(gè)與代碼執(zhí)行速度有關(guān)的性能問題都?xì)w結(jié)為有多少條指令被執(zhí)行和被執(zhí)行多少次

5.7.?當(dāng)你優(yōu)化代碼時(shí)，本質(zhì)上你要做的是減少指令的執(zhí)行次數(shù)，或者使用更快版本的指令

6.?從頭開始

6.1.?直接在源頭解決問題

6.1.1.?定位到根本問題

6.2.?減少執(zhí)行指令數(shù)量第二好的方法是選擇一個(gè)更快的算法

6.3.?最好的方法顯然是完全刪除代碼

6.3.1.?刪除你不需要的代碼

6.3.2.?不要在代碼庫中保留不需要的代碼

6.3.2.1.?即使不會直接降低代碼的性能，也會降低開發(fā)人員的“性能”，最終降低代碼的性能

6.3.3.?不要保留注釋過的代碼

6.3.3.1.?可以使用你最喜歡的源代碼控制系統(tǒng)（如Git或Mercurial）的歷史功能來恢復(fù)舊代碼

6.4.?讓代碼運(yùn)行速度變慢的最簡單的方法之一是把它放在另一個(gè)循環(huán)里

6.4.1.?不應(yīng)該把計(jì)算密集型的代碼放在屬性的源代碼里面

6.4.2.?小心屬性

6.4.2.1.?它們包含邏輯，而它們的邏輯并不簡單

6.5.?面向字符串的編程

6.5.1.?選擇適合的類型會比使用字符串擁有更好的性能

6.5.2.?字符串有一些微妙的方式可以被添加進(jìn)你的代碼里

6.5.3.?一個(gè)布爾變量來優(yōu)化代碼

6.5.3.1.?C#

if ((string)HttpContext.Items["Bozo"] == "true") {
...
}

6.5.3.2.?C#

if ((bool?)HttpContext.Items["Bozo"] == true) {
...
}

6.5.3.3.?節(jié)省存儲開銷和解析開銷，還有助于避免你的打字錯(cuò)誤，比如把True打成ture

6.5.3.4.?簡單的錯(cuò)誤對你來說影響不是特別大，但如果錯(cuò)誤變成了習(xí)慣，影響就會積小成大

6.6.?if語句中的布爾表達(dá)式是按照它們的書寫順序來評估

6.6.1.?可以簡單地調(diào)換表達(dá)式的位置

6.6.2.?建議根據(jù)操作數(shù)類型對表達(dá)式進(jìn)行排序

6.6.2.1.?1.變量

6.6.2.2.?2.字段

6.6.2.3.?3.屬性

6.6.2.4.?4.方法調(diào)用

6.6.3.?邏輯符號是有優(yōu)先級之說的，以確保你在優(yōu)化布爾運(yùn)算時(shí)不會意外地破壞if語句中的邏輯