1 回答

TA貢獻1853條經驗 獲得超6個贊
并發不是并行。通道的這種特殊使用結果與僅從 返回值非常相似removeDuplicates
,只是兩個 goroutine 需要協調它們對通道的使用會產生額外的開銷。
具體來說:
循環的每次迭代都有自己的通道,每個通道只能容納一個元素。
在所有語句都已執行之前,循環無法繼續下一次迭代,包括對該語句的調用
log.Printf
阻塞,直到從通道接收到值。removeDuplicates
檢測到實時時間已經過去了多少,而不是在解決問題上花費了多少時間。這是評論說它首先不是一個很好的基準的眾多原因之一。
推測:在循環的前幾次迭代中,goroutine 可能removeDuplicates
會初始化start
,然后將執行時間交給主 goroutine。然后 main goroutine 立即檢查 mutex on?c
,發現它還不能做任何事情,并返回給調度程序,所有這些檢查和上下文切換增加了數千納秒(關心這通常是微基準測試的味道)到goroutineremoveDuplicates
的實時執行。main
在幾次迭代之后,某些東西(也許是 Go 運行時)發現了在返回之前永遠無法取得進展的事實removeDuplicates
,并且避免了上下文切換。
我知道此時您對解釋比建議更感興趣,但如果我不指出比較 Go 和 Java 的基準已經存在,我會覺得很不負責任。即使您想自己編寫,我也建議使用類似的方法:根據需要完成的任務定義基準程序,然后使用每種語言(或框架)中可用的最佳工具來完成工作具有良好的性能。
- 1 回答
- 0 關注
- 125 瀏覽
添加回答
舉報