1. 理解可變性
1.1. 理解測驗結果如何隨時間變化
1.2. 可以通過多次運行測驗后取平均值來解決
1.3. 因代碼改進而進行的測驗叫作回歸測驗（regression testing）
-
1.3.1. 原本的代碼叫作基線（baseline）
-
1.3.2. 新的代碼叫作樣本（specimen）
1.4. 結果的變化越大，越難判斷平均值的差異是由于真正的性能問題還是隨機變化
1.5. 正確判斷兩個測驗的結果是否有差異需要進行一定程度的統計分析，以確保感知到的差異不是隨機波動造成的
-
1.5.1. 要進行嚴謹的統計分析，可以使用T檢驗比較測驗結果
-
1.5.2. 檢驗的結果表示出現性能倒退的概率，但是它并不能顯示出哪些倒退應該忽略，哪些應該追蹤，在這兩者間找到平衡是一種性能工程藝術
2. 早測驗、常測驗
2.1. 性能測驗作為開發周期中的必要部分
2.2. 早期測驗帶來的問題
-
2.2.1. 受發布時間的限制，開發人員需要盡快檢入代碼
-
2.2.2. 代碼的性能特征會隨著代碼的變化而變化
2.3. 自動化一切
- 2.3.1. 所有的性能測驗都應該腳本化（或者程式化，不過腳本化通常更容易）
2.4. 測量一切
- 2.4.1. 自動化必須收集可以想到的每一份資料，以便用于以后的分析
2.5. 在目標系統上運行
-
2.5.1. 很多重要的調優標志會基于JVM運行的底層硬體系統，計算出它們的默認值
-
2.5.2. 不同平臺的代碼編譯方式不同
-
2.5.3. 軟體快取和更重要的硬體快取，在不同的系統和不同的負載下的表現也不同
3. jmh提供微基準測驗
3.1. 適用于納（nano）/微（micro）/毫（milli）/宏（macro）等規模的基準測驗
3.2. 隨著Java 9一起發布的
-
3.2.1. 組成jmh的類別庫兼容JDK 8及之后的版本
-
3.2.2. 并沒有與任何具體的Java版本系結
-
3.2.3. JDK中沒有支持jmh的工具
3.3. Blackhole類是jmh的特性
-
3.3.1. 解決了微基準測驗的一個重要問題：如果一個操作的值沒有用到，那么編譯器會直接優化這個操作
-
3.3.2. 所以把值傳遞給Blackhole的consume()方法可以確保值被使用
3.4. Setup注解的Level值
-
3.4.1. Level.Trial
- 3.4.1.1. 在基準測驗代碼初始化時執行一次
-
3.4.2. Level.Iteration
- 3.4.2.1. 在基準測驗每次迭代前完成（每個測量期）
-
3.4.3. Level.Invocation
- 3.4.3.1. 在每次測驗方法執行之前完成
3.5. -f 5
- 3.5.1. 派生試驗的運行次數（默認為5）
3.6. -wi 5
- 3.6.1. 每次試驗的預熱迭代次數（默認為5）
3.7. -i 5
- 3.7.1. 每次試驗的測量迭代次數（默認為5）
3.8. -r 10
-
3.8.1. 每次迭代的最少時間（以秒為單位）
-
3.8.2. 迭代的時間可能比這個時間長，具體取決于目標方法的實際執行時間
3.9. 對于更穩定的測驗，降低這些引數的值一般可以縮短運行測驗所需的時間
3.10. 通常讓Java代碼變得更好、更快的方法是寫出更好的演算法，但這個實作與任何Java調優實踐或者Java編碼實踐無關
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/547902.html
標籤：其他