在处理一些速度较慢的完全模拟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
默认变慢。