我有一個報告了性能問題的 .NET 應用程式。我之前關于如何提高性能的問題已關閉。評論告訴我，我沒有正確進行性能測量，也沒有遵循性能改程序序。
那么，該程序是什么以及如何正確執行 .NET 的性能測驗？
uj5u.com熱心網友回復：
那么，該程序是什么以及如何正確執行 .NET 的性能測驗？
第 1 步：閱讀@Eric Lippert的性能文章
基準測驗錯誤，第 1部分是關于
- 錯誤 #1：選擇一個不好的指標
- 錯誤 #2：以犧牲端到端性能為代價過度關注子系統性能
- 錯誤 #3：在除錯器中運行基準測驗
- 錯誤 #4：對除錯版本而不是發布版本進行基準測驗
基準測驗錯誤，第 2 部分
- 錯誤 #5：使用時鐘而不是秒表
基準測驗錯誤，第 3 部分
- 錯誤 #6：在衡量平均性能時，將第一次運行視為沒有什么特別之處
- 錯誤 #7：假設一個環境中的運行時特征告訴您在不同環境中的行為
基準測驗錯誤，第 4 部分
- 錯誤 #8：忘記考慮垃圾收集效應。
第 2 步：了解Eric Lippert 的性能文章。再次閱讀它們并弄清楚您將如何將這些概念應用于您的程式、IDE 等。您如何在發布模式下進行編譯？如何在沒有除錯器的情況下運行？您如何實施時間測量？
第 3 步：制定清單以確保您遵循所有建議
第 4 步：獲取您的性能性能要求。確切地說，它需要多快？在絕對值中，在哪個硬體上？
可以使用您的機器作為參考。但是我們需要知道它是什么機器才能了解它具有哪些功能（例如 CPU、快取級別、turbo boost 是否激活、超執行緒是否激活）。
第 5 步：配置您的應用程式。使用合適的工具。
許多公司將 JetBrains dotTrace 作為 Resharper Ultimate 的一部分。
第 6 步：分析結果。熱點和瓶頸在哪里？你是怎么找到他們的？它們是由工具建議的嗎？如果有，是哪一個？
第 7 步：考慮可能的優化
將多執行緒引入之前是順序的問題可能會給您帶來 8 倍的性能。更好的演算法可以輕松為您帶來 20 倍的性能（非多執行緒）。這一步要好好想想。
第 8 步：預測不同的選項。您期望每個選項的性能提升多少？
如果所有選項都沒有達到所需的性能，您甚至可能不想開始接觸代碼。
第 9 步：設定版本控制，因為您將需要它。
請參閱步驟 13。您必須能夠回滾。您可能會弄錯多執行緒并導致資料競爭。您的優化結果可能比以前更糟。您必須能夠回滾到干凈的狀態。
第 10 步：實施（下一個）最有希望的選項
第 11 步：驗證結果，即再次組態檔（在同一臺機器上，相同的設定，...）
第 12 步：將新結果與初始結果進行比較。
第 13 步：如果更改良好，則保留更改，否則回滾。
步驟14：如果達到性能目標：停止。如果沒有，請回傳到步驟 7 或 8 并實施其他選項之一。
停止意味著：不執行更多。您已達到要求。不要通過優化更多來浪費您的時間。“過早的優化是萬惡之源”[Donald Knuth]
我之前關于如何提高性能的問題已關閉。
在 Stack Overflow 上詢問性能問題時：
- 提供證據證明您具備基本知識。
- 提供您遵守規則的證據（例如發布版本，...）。
- 提供您正在優化的指標。
- 提供您的硬體詳細資訊。
- 不要發布數百行代碼的鏈接。將受影響的代碼減少到最低限度。
- 在BenchmarkDotNet 中運行最小化的代碼，因為
- 開箱即用，它做了很多正確的事情（比如平均）
- 它是免費的，所以每個人都可以用它來驗證你的結果
- 提供數字 - 步驟 4、5 和 11 中的所有數字 (!)。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/379352.html