<p>every time I made a modification, go test takes a long time to run. I only run a single test, like,
go test pkg/ds/ds... -run TestCase1 -v</p>
<hr/>**评论：**<br/><br/>silenceofnight: <pre><p>It rebuilds the related binary every time.</p>
<p>You can make subsequent test runs faster by first running <code>go test -i ./pkg/blah/...</code> before running <code>go test ./pkg/blah/...</code></p></pre>losinggeneration: <pre><p>To elaborate a bit more, it's having to build the binary and all dependences. Pure Go packages are pretty quick to compile, but lots of dependencies can take a bit of time to find on disk and compile. If any of the code has any C or C++ to compile, the compile time goes up significantly (sqlite for example.) </p>
<p>e: If the packages are installed, as mentioned with go test -i, it doesn't have to recompile the dependencies (unless their source has changed.)</p></pre>marksteve4: <pre><p>this is just the same slow if not slower. How about -c?</p></pre>jerf: <pre><p><code>-c</code> would skip the step where it runs the test and you'd have to run it yourself. While this might, ironically, make it feel faster, it would not actually be faster.</p>
<p>If it isn't being fixed by <code>go test -i</code>, which was my first thought as well, the next thing to try is running <code>go test -v</code> and just watching the output. If the first output <code>=== RUN (your test name)</code> comes out quickly, then the compile is happening quickly enough; you may have a slow test.</p>
<p>If that still isn't fast, and if you are not compiling an excessive amount of code in your package or linking to an excessive number of packages (lots and lots of "import" packages, like, many dozens), the next thing I would be looking at is the system itself; are you in swap? Is something eating 100% of your CPU that you didn't know about? Have a look at your hard drive's SMART statistics, too. I have had hard drives that "work" but are actually throwing errors every which way, in which case you need to stop working on your Go program and start getting everything off the drive. (Long shot in terms of fixing this problem, but worth mentioning due to the high potential impact.)</p>
<p>Failing all that, I think we'd need to see the test code in question, if at all possible. Right now, with all due respect, your report is basically "It's slow. Why?" There's not a lot to grab on to, there; we barely even have a hint what "it" is. <a href="http://www.catb.org/esr/faqs/smart-questions.html" rel="nofollow">You may find this helpful</a>.</p></pre>marksteve4: <pre><p>This is a great answer. Thanks</p></pre>j_d_q: <pre><p>I'd also throw in <code>-x</code> to see what it's doing before it runs</p></pre>
