檢查效能分析和程式碼效率

  • 5 分鐘

在軟體開發中， 效能是一個特徵。 程式在功能上可能是正確的，但如果它太慢或資源匱乏，使用者就會感到沮喪，並且可能會失去商機。

考慮以下行業觀察：

  • 對於電子商務平台來說，每增加 100 毫秒的延遲就會損失大約 1% 的銷售額。 在大批量場景中，即使是幾分之一秒也可能導致數百萬美元的收入損失。
  • 將搜尋結果減慢半秒就可以減少 20%的流量。 用戶期望快速回應。 如果您的應用程式滯後，他們可能會切換到替代方案。

這些觀察結果強調了一個基本事實： 快速的軟體提供了更好的使用者體驗，並且通常與成功指標 （銷售、參與度、保留率）直接相關。 對於內部或後端系統，效能會轉化為效率 （例如，每秒處理更多交易或降低雲端成本）。

然而，實現高效能並不是瘋狂的猜測或痴迷地優化每一行程式碼。 這是關於找到重要的特定領域並改進它們——這就是 績效分析 的用武之地。

什麼是效能分析？

效能分析是分析程式以瞭解資源使用方式的過程，主要是 CPU 時間、記憶體、磁碟/網路 I/O 等。分析器 （或分析技術） 有助於回答下列類型的問題：

  • 哪些函數或操作消耗的時間最多？
  • 記憶體使用量在哪裡激增？
  • 這個代碼被調用了多少次？ 是否有冗餘操作？
  • 應用程式是否正在等待外部資源 （例如資料庫或檔案系統）？

分析本質上是對程式碼運行時行為的偵探工作。 您無需猜測放緩的可能位置，而是收集資料來查明它。

作為開發人員，您可能會對什麼是慢的有預感，但直覺可能會產生誤導。 換句話說：

  • 不要花精力優化那些97%並非時間緊迫的代碼，這些代碼實際上並不是瓶頸。
  • 請將「關鍵 3%」(分析顯示為效能熱點的程式碼部分) 最佳化。

訣竅是 識別 關鍵的 3%，而這正是分析工具和技術可以幫助您做到的。

效能分析工具

若要有效地分析您的應用程式，您需要正確的工具。 有各種可用的分析工具，從簡單的內建類別到複雜的行業工具和解決方案。

用於基本計時測量的秒錶

System.Diagnostics.Stopwatch.NET 中的類別提供測量執行時間的簡單方法。 它非常適合快速、有針對性的測量：

var stopwatch = Stopwatch.StartNew();
// Code to measure
stopwatch.Stop();
Console.WriteLine($"Execution time: {stopwatch.ElapsedMilliseconds} ms");

雖然秒錶對於基本計時很有用，但它無法提供有關記憶體使用情況或方法級效能故障的詳細見解。

BenchmarkDotNet 用於全面基準測試

BenchmarkDotNet 是一個功能強大的 .NET 函式庫，專為準確的效能基準測試而設計。 它會自動處理常見的基準測試陷阱，例如即時 （JIT） 編譯、垃圾收集干擾和測量精度：

[MemoryDiagnoser]
public class MyBenchmark
{
    [Benchmark]
    public void Method1() => // Implementation
    
    [Benchmark]
    public void Method2() => // Implementation
}

BenchmarkDotNet 提供統計分析、記憶體分配追蹤，並可以並排比較多個實作，使其成為驗證最佳化工作的理想選擇。

備註

此訓練模組不涵蓋如何實作分析工具。 不過，本模組將於後續部分中更詳細地討論分析工具，而練習中使用的範例應用程式示範如何使用 Stopwatch 和 BenchmarkDotNet 工具。

在整個開發過程中考慮程式碼效率

最好在整個開發生命週期中納入效能考慮。

設計階段

考慮針對您的問題的高效演算法和適當的資料結構。 如果您預期要處理數百萬筆記錄，則 O（n²） 解決方案可能會成為問題。 早期的高階決策 （例如，使用資料庫與記憶體內處理，或在清單和雜湊集之間進行選擇以進行查閱） 對效能有重大影響。

實施階段

在初始開發期間清晰且有效率地編寫程式碼。 不要過早地進行微優化，但要注意明顯的低效率。 例如，如果您需要經常檢查成員資格，使用HashSet而不是重複掃描列表，不僅意圖更加明確，而且速度更快。

程式碼測試和分析階段

當您的程式碼或功能正常運作時，請測量其效能。 建立基線（速度有多快？它使用多少內存？如果它符合您的目標（例如，報告在 2 秒內生成，或使用量保持在 1 GB 內存以下），那就太好了。 如果沒有，請使用分析來調查。

最佳化與迭代

首先關注最慢的部分。 通常，改善一兩個瓶頸會產生巨大的好處。 通常， 80% 的執行時間花在 20%（或更少）的程式碼中 ——這是軟體中帕累托原理的變體。 分析有助於找到關鍵的 20%。 進行變更之後，請再次測試以驗證改進，並確保沒有造成任何問題。

持續監控

在生產或大規模生產中，請密切注意效能指標。 使用應用程式監視工具 （例如 Application Insights，如果您使用的是 Azure） 或其他工具，來攔截任何迴歸的效能。 實際使用情況可能會顯示不同的熱點 （例如，隨著資料量的成長或使用模式的變更）。

常見的效能陷阱 （非 GUI）

許多後端或一般程式碼效能問題是眾所周知的。

下列項目提供快速概觀：

  • 演算法效率低下： 使用效率低於必要的演算法或方法。 範例：O（n²）排序、有公式的暴力運算等。
  • 過多的 I/O 或外部呼叫： 在緊密迴圈內從磁碟讀取、進行過多的資料庫查詢（N+1查詢問題）或阻塞主執行緒上的網路呼叫。
  • 低效的資料存取模式： 例如，不在資料庫查詢中使用索引，或重複搜尋清單而不是使用查找結構。
  • 記憶體濫用： 不必要地建立大型物件或大量小型物件，導致大量垃圾回收。 持續保留引用的時間過長（導致記憶體消耗過多）或不釋放資源，均可能降低效能。
  • 缺乏並行性或平行處理原則：在工作可以並行完成時 (在多核系統上或非同步等候輸入/輸出) 按順序執行所有內容。 或者，相反的陷阱是濫用並行性，使額外負荷超過優點，或引發爭用。
  • 封鎖作業：使用封鎖等候 (Thread.Sleep、非同步內容中的同步輸入/輸出等)，讓進度停滯不前。

GitHub Copilot 與分析

GitHub Copilot （尤其是 GitHub Copilot Agent） 是您工具箱中的新工具。 它不是分析器，但它可以像 AI 配對程式設計師 一樣，擁有大量常見效能問題和修復的記憶體。 例如：

  • GitHub Copilot 可以向你解釋程式碼：「這個函數是否在做任何低效的事情？」例如，它可能會指出，一個特定的循環正在每次迭代時進行資料庫調用，這樣的成本很高。
  • GitHub Copilot 可以提出改進建議：「如何加快此程式碼的速度？」它可能會建議使用不同的方法（例如， StringBuilder 在循環中使用 for 字串串連，這是 C# 中已知的效能最佳實踐）。
  • 如果您提示，GitHub Copilot 可以產生重構的程式碼，從而節省您實作最佳化的時間。

將 GitHub Copilot 視為一個助手，他閱讀了無數有關效能的開發人員論壇、文件頁面和社群討論。 它不會取代您的理解，但可以加速識別和應用優化的過程。

總結

效能分析對於旨在建立高效、響應式應用程式的開發人員來說是一項關鍵技能。 透過系統地測量和分析程式碼效能，您可以識別瓶頸並優化最重要的部分。 在整個開發生命週期（從設計到持續監控）中整合效能考量，確保您的應用程式不僅正常運作，而且提供卓越的使用者體驗。