go - Go testing.B ベンチマークは不要な最適化を防ぎますか?

Question

私は最近 Go の学習を開始し、複数のグラルーチンで同時に使用できるマップを実装しようとしています。sync.Mutex実装を単純な保護されたマップ、または次のようなものと比較できるようにしたい: https://github.com/streamrail/concurrent-map/blob/master/concurrent_map.go

Google Caliper を使用することから、ベンチマークの単純なアプローチでは、多くの望ましくない最適化が実際の結果を台無しにする可能性があると思います。それを回避するためにいくつかの手法を使用するベンチマークはありますtesting.Bか (結局のところ、Go と Caliper はどちらも Google プロジェクトです)。はいの場合、それらは知られていますか? そうでない場合、Go でマイクロベンチマークを行う最良の方法は何ですか?

Answer 1

Java では、Hotspot コンパイラーの仕組みが原因で、マイクロ ベンチマークを実行するのが難しくなります。同じコードを単純に何度も実行すると、多くの場合、平均よりも速くなることがわかります。これを補うために、Caliper は、安定したベンチマークを取得するために、いくつかのウォームアップ ランやその他のトリックを実行する必要があります。

Go では、物事は静的にコンパイルされます。システムのような実行時のホットスポットはありません。良いタイミングを得るためにトリックを行う必要はありません。

testing.B 機能は、コードのパフォーマンスに影響を与えるべきではないため、特別なことを行う必要はありません。