newbie question - why does golang benchmark result varies widely for multiple run of the same code.

<p>Here is a list of my benchmark result</p> <pre><code>// One function that uses goroutine 300000 8213 ns/op 300000 6364 ns/op 500000 5611 ns/op 300000 6243 ns/op 300000 6003 ns/op 500000 11680 ns/op // One function that does not use goroutine 3000000 425 ns/op 3000000 527 ns/op 3000000 445 ns/op 3000000 507 ns/op 3000000 676 ns/op 3000000 454 ns/op </code></pre> <p>The range for each benchmark is crazy, am I doing something wrong?</p> <hr/>**评论：**<br/><br/>dlsniper: <pre><p>There&#39;s only one correct answer: Show us the code. Without it, nobody can give you a proper explanation of what&#39;s happening.</p></pre>jerf: <pre><p>dlsniper is broadly correct, but first guess for that level of variation is that the rest of your system is not quiet. Double check with your system monitor that you haven&#39;t got other active processes.</p></pre>dlsniper: <pre><p>Actually no, for those variations to be explainable you&#39;d have to put the CPU from high performance mode to power saving while the CPU is doing a bunch of other things. The likely cause is garbage generated by the code in the goroutine and how that goroutine is used but without the code nobody can explain it. It&#39;s like asking your mechanic about a &#34;strange sound&#34; you hear in the engine without having the car with you. </p></pre>TheMerovius: <pre><p>FWIW, ~10μs [edit: ah, no, it was ~1μs. But still] is roughly what I observed at some point, when I tried to measure how long it takes for a goroutine to start up. So, from what little information you gave us (&#34;something, something goroutines&#34;), this doesn&#39;t seem all that surprising to me.</p></pre>deusmetallum: <pre><p>When you&#39;re using go routines, it essentially forks the process, which requires more system resources to perform. If you don&#39;t need to do things asynchronously then there&#39;s no point in using go routines.</p></pre>dlsspy: <pre><p>That&#39;s very misleading. A goroutine has so little in common with forking a process that it&#39;s not even relevant.</p></pre>TrueFurby: <pre><p>The go routines were more or less basically created for the entire reason you just described. The relieve developers from the burden of threads.</p></pre>