回到简体

ch11/ch11-04.md

@@ -1,8 +1,8 @@
-## 11.4. 基準測試
+## 11.4. 基准测试
 
-基準測試是測量一個程序在固定工作負載下的性能。在Go語言中，基準測試函數和普通測試函數寫法類似，但是以Benchmark爲前綴名，併且帶有一個`*testing.B`類型的參數；`*testing.B`參數除了提供和`*testing.T`類似的方法，還有額外一些和性能測量相關的方法。它還提供了一個整數N，用於指定操作執行的循環次數。
+基准测试是测量一个程序在固定工作负载下的性能。在Go语言中，基准测试函数和普通测试函数写法类似，但是以Benchmark为前缀名，并且带有一个`*testing.B`类型的参数；`*testing.B`参数除了提供和`*testing.T`类似的方法，还有额外一些和性能测量相关的方法。它还提供了一个整数N，用于指定操作执行的循环次数。
 
-下面是IsPalindrome函數的基準測試，其中循環將執行N次。
+下面是IsPalindrome函数的基准测试，其中循环将执行N次。
 
 ```Go
 import "testing"
@@ -14,7 +14,7 @@ func BenchmarkIsPalindrome(b *testing.B) {
 }
 ```
 
-我們用下面的命令運行基準測試。和普通測試不同的是，默認情況下不運行任何基準測試。我們需要通過`-bench`命令行標誌參數手工指定要運行的基準測試函數。該參數是一個正則表達式，用於匹配要執行的基準測試函數的名字，默認值是空的。其中“.”模式將可以匹配所有基準測試函數，但是這里總共隻有一個基準測試函數，因此和`-bench=IsPalindrome`參數是等價的效果。
+我们用下面的命令运行基准测试。和普通测试不同的是，默认情况下不运行任何基准测试。我们需要通过`-bench`命令行标志参数手工指定要运行的基准测试函数。该参数是一个正则表达式，用于匹配要执行的基准测试函数的名字，默认值是空的。其中“.”模式将可以匹配所有基准测试函数，但是这里总共只有一个基准测试函数，因此和`-bench=IsPalindrome`参数是等价的效果。
 
 ```
 $ cd $GOPATH/src/gopl.io/ch11/word2
@@ -24,13 +24,13 @@ BenchmarkIsPalindrome-8 1000000                1035 ns/op
 ok      gopl.io/ch11/word2      2.179s
 ```
 
-結果中基準測試名的數字後綴部分，這里是8，表示運行時對應的GOMAXPROCS的值，這對於一些和併發相關的基準測試是重要的信息。
+结果中基准测试名的数字后缀部分，这里是8，表示运行时对应的GOMAXPROCS的值，这对于一些和并发相关的基准测试是重要的信息。
 
-報告顯示每次調用IsPalindrome函數花費1.035微秒，是執行1,000,000次的平均時間。因爲基準測試驅動器開始時併不知道每個基準測試函數運行所花的時間，它會嚐試在眞正運行基準測試前先嚐試用較小的N運行測試來估算基準測試函數所需要的時間，然後推斷一個較大的時間保證穩定的測量結果。
+报告显示每次调用IsPalindrome函数花费1.035微秒，是执行1,000,000次的平均时间。因为基准测试驱动器开始时并不知道每个基准测试函数运行所花的时间，它会尝试在真正运行基准测试前先尝试用较小的N运行测试来估算基准测试函数所需要的时间，然后推断一个较大的时间保证稳定的测量结果。
 
-循環在基準測試函數內實現，而不是放在基準測試框架內實現，這樣可以讓每個基準測試函數有機會在循環啟動前執行初始化代碼，這樣併不會顯著影響每次迭代的平均運行時間。如果還是擔心初始化代碼部分對測量時間帶來榦擾，那麽可以通過testing.B參數提供的方法來臨時關閉或重置計時器，不過這些一般很少會用到。
+循环在基准测试函数内实现，而不是放在基准测试框架内实现，这样可以让每个基准测试函数有机会在循环启动前执行初始化代码，这样并不会显著影响每次迭代的平均运行时间。如果还是担心初始化代码部分对测量时间带来干扰，那么可以通过testing.B参数提供的方法来临时关闭或重置计时器，不过这些一般很少会用到。
 
-現在我們有了一個基準測試和普通測試，我們可以很容易測試新的讓程序運行更快的想法。也許最明顯的優化是在IsPalindrome函數中第二個循環的停止檢査，這樣可以避免每個比較都做兩次：
+现在我们有了一个基准测试和普通测试，我们可以很容易测试新的让程序运行更快的想法。也许最明显的优化是在IsPalindrome函数中第二个循环的停止检查，这样可以避免每个比较都做两次：
 
 ```Go
 n := len(letters)/2
@@ -42,7 +42,7 @@ for i := 0; i < n; i++ {
 return true
 ```
 
-不過很多情況下，一個明顯的優化併不一定就能代碼預期的效果。這個改進在基準測試中隻帶來了4%的性能提陞。
+不过很多情况下，一个明显的优化并不一定就能代码预期的效果。这个改进在基准测试中只带来了4%的性能提升。
 
 ```
 $ go test -bench=.
@@ -51,7 +51,7 @@ BenchmarkIsPalindrome-8 1000000              992 ns/op
 ok      gopl.io/ch11/word2      2.093s
 ```
 
-另一個改進想法是在開始爲每個字符預先分配一個足夠大的數組，這樣就可以避免在append調用時可能會導致內存的多次重新分配。聲明一個letters數組變量，併指定合適的大小，像下面這樣，
+另一个改进想法是在开始为每个字符预先分配一个足够大的数组，这样就可以避免在append调用时可能会导致内存的多次重新分配。声明一个letters数组变量，并指定合适的大小，像下面这样，
 
 ```Go
 letters := make([]rune, 0, len(s))
@@ -62,7 +62,7 @@ for _, r := range s {
 }
 ```
 
-這個改進提陞性能約35%，報告結果是基於2,000,000次迭代的平均運行時間統計。
+这个改进提升性能约35%，报告结果是基于2,000,000次迭代的平均运行时间统计。
 
 ```
 $ go test -bench=.
@@ -71,7 +71,7 @@ BenchmarkIsPalindrome-8 2000000                      697 ns/op
 ok      gopl.io/ch11/word2      1.468s
 ```
 
-如這個例子所示，快的程序往往是伴隨着較少的內存分配。`-benchmem`命令行標誌參數將在報告中包含內存的分配數據統計。我們可以比較優化前後內存的分配情況：
+如这个例子所示，快的程序往往是伴随着较少的内存分配。`-benchmem`命令行标志参数将在报告中包含内存的分配数据统计。我们可以比较优化前后内存的分配情况：
 
 ```
 $ go test -bench=. -benchmem
@@ -79,7 +79,7 @@ PASS
 BenchmarkIsPalindrome    1000000   1026 ns/op    304 B/op  4 allocs/op
 ```
 
-這是優化之後的結果：
+这是优化之后的结果：
 
 ```
 $ go test -bench=. -benchmem
@@ -87,11 +87,11 @@ PASS
 BenchmarkIsPalindrome    2000000    807 ns/op    128 B/op  1 allocs/op
 ```
 
-用一次內存分配代替多次的內存分配節省了75%的分配調用次數和減少近一半的內存需求。
+用一次内存分配代替多次的内存分配节省了75%的分配调用次数和减少近一半的内存需求。
 
-這個基準測試告訴我們所需的絶對時間依賴給定的具體操作，兩個不同的操作所需時間的差異也是和不同環境相關的。例如，如果一個函數需要1ms處理1,000個元素，那麽處理10000或1百萬將需要多少時間呢？這樣的比較揭示了漸近增長函數的運行時間。另一個例子：I/O緩存該設置爲多大呢？基準測試可以幫助我們選擇較小的緩存但能帶來滿意的性能。第三個例子：對於一個確定的工作那種算法更好？基準測試可以評估兩種不同算法對於相同的輸入在不同的場景和負載下的優缺點。
+这个基准测试告诉我们所需的绝对时间依赖给定的具体操作，两个不同的操作所需时间的差异也是和不同环境相关的。例如，如果一个函数需要1ms处理1,000个元素，那么处理10000或1百万将需要多少时间呢？这样的比较揭示了渐近增长函数的运行时间。另一个例子：I/O缓存该设置为多大呢？基准测试可以帮助我们选择较小的缓存但能带来满意的性能。第三个例子：对于一个确定的工作那种算法更好？基准测试可以评估两种不同算法对于相同的输入在不同的场景和负载下的优缺点。
 
-一般比較基準測試都是結構類似的代碼。它們通常是采用一個參數的函數，從幾個標誌的基準測試函數入口調用，就像這樣：
+一般比较基准测试都是结构类似的代码。它们通常是采用一个参数的函数，从几个标志的基准测试函数入口调用，就像这样：
 
 ```Go
 func benchmark(b *testing.B, size int) { /* ... */ }
@@ -100,13 +100,13 @@ func Benchmark100(b *testing.B)        { benchmark(b, 100) }
 func Benchmark1000(b *testing.B)       { benchmark(b, 1000) }
 ```
 
-通過函數參數來指定輸入的大小，但是參數變量對於每個具體的基準測試都是固定的。要避免直接脩改b.N來控製輸入的大小。除非你將它作爲一個固定大小的迭代計算輸入，否則基準測試的結果將毫無意義。
+通过函数参数来指定输入的大小，但是参数变量对于每个具体的基准测试都是固定的。要避免直接修改b.N来控制输入的大小。除非你将它作为一个固定大小的迭代计算输入，否则基准测试的结果将毫无意义。
 
-基準測試對於編寫代碼是很有幫助的，但是卽使工作完成了也應當保存基準測試代碼。因爲隨着項目的發展，或者是輸入的增加，或者是部署到新的操作繫統或不同的處理器，我們可以再次用基準測試來幫助我們改進設計。
+基准测试对于编写代码是很有帮助的，但是即使工作完成了也应当保存基准测试代码。因为随着项目的发展，或者是输入的增加，或者是部署到新的操作系统或不同的处理器，我们可以再次用基准测试来帮助我们改进设计。
 
-**練習 11.6:** 爲2.6.2節的練習2.4和練習2.5的PopCount函數編寫基準測試。看看基於表格算法在不同情況下對提陞性能會有多大幫助。
+**练习 11.6:** 为2.6.2节的练习2.4和练习2.5的PopCount函数编写基准测试。看看基于表格算法在不同情况下对提升性能会有多大帮助。
 
-**練習 11.7:** 爲\*IntSet（§6.5）的Add、UnionWith和其他方法編寫基準測試，使用大量隨機輸入。你可以讓這些方法跑多快？選擇字的大小對於性能的影響如何？IntSet和基於內建map的實現相比有多快？
+**练习 11.7:** 为\*IntSet（§6.5）的Add、UnionWith和其他方法编写基准测试，使用大量随机输入。你可以让这些方法跑多快？选择字的大小对于性能的影响如何？IntSet和基于内建map的实现相比有多快？