在处理一些速度较慢的完全模拟QEMU虚拟机时，我注意到go test -c比预期要慢得多。查看top,我看到vet在吃CPU。
这似乎令人惊讶，因为我们默认在描述为：
将测试二进制文件编译为pkg.test,但不运行它
任何vet输出都看起来像一个测试失败并因此运行，即使它不是技术上的测试。
我建议我们关闭-c的vet功能。@bcmills, @jayconrod, @ianlancetaylor, @rsc?
无论如何，这不是关键问题。现在我知道要在-c上始终使用-vet=off:
gopher@buildlet:~/go/src/io$ time ../../bin/go test -c
real 0m28.740s
user 0m14.184s
sys 0m9.208s
gopher@buildlet:~/go/src/io$ time ../../bin/go test -c -vet=off
real 0m19.385s
user 0m9.772s
sys 0m6.488s
gopher@buildlet:~/go/src/io$ time ../../bin/go test -c
real 0m28.651s
user 0m16.804s
sys 0m10.260s
gopher@buildlet:~/go/src/io$ time ../../bin/go test -c -vet=off
real 0m18.051s
user 0m10.504s
sys 0m6.692s标记为Go 1.14版本，除非这是一个最近的回归。我没有检查。
3条答案
按热度按时间thtygnil1#
该功能在 #26451 中添加。
7xzttuei2#
在
go test -c过程中关闭vet步骤的问题是，它可能会完全掩盖vet的输出：通常情况下，一个go test -c调用对应于稍后手动运行二进制文件以获取测试的输出，我认为我们不应该将vet警告嵌入到实际的测试二进制文件中，这意味着vet诊断信息永远不会呈现给用户。我理解为什么这令人惊讶，但——特别是考虑到
-vet=off的解决方法——我认为我们不应该隐式地禁用vet步骤。wlzqhblo3#
@bcmills ,鉴于运行软件包测试的标准方法是
go test,而不是go test -c && ./pkg.test,我认为 vet 警告不会被长时间掩盖。也许有一台用户或机器会不小心忽略 vet 一段时间，但我想象其他机器或人类会很快开始看到 vet 警告。
我不认为我们应该告诉那些只想使用
go test -c(以及旧的、不意外的行为)的人也使用-vet=off。我意识到保持谨慎通常是个好主意，但我不认为我们应该为了它而让go test -c默认变慢。