从Go 1.10到1.11是否存在显著的回归？如果没有，那么在树重新开放时这样做似乎是最安全和最简单的方法。

首先，应该对Go 1.10和tip的复用器进行基准测试。如果它真的很糟糕，我们可以调查并为Go 1.11做一个最小的性能修复。否则，这都是Go 1.12的内容。
我暂时假设它是Go 1.12,但某人仍然应该尽快对其进行基准测试。

@mvdan 很好的问题！到目前为止，促使这个问题出现的是 #25383,这是手动发现的。同意，也许在树打开时会触发。
也许我们甚至可以制作工具，将其作为Trybots的一部分运行基准测试，并在出现巨大波动(例如 |8%|)时报告。我曾参与过一些内部工具的开发，但我需要花时间打包它

或许我们甚至可以制作一个工具，将其作为Trybots的一部分运行基准测试，并在出现巨大波动(例如 |8%| )时报告。我曾参与过一些内部工具的开发，但我需要时间来打包它。
这不是一个小项目。
已经完成过两次，但两次都被放弃了。
第一次是 #8930 (评论),第二次是当前的 #20552 。

Roger,感谢你的警告故事@bradfitz!
好的，对于一些结果，我在Go1.10和tip devel 87a18c6上运行了所有的net/http基准测试，结果如下：
我的机器信息

Darwin Emmanuels-MacBook-Pro-2.local 15.6.0 Darwin Kernel Version 15.6.0: Tue Jan  9 20:12:05 PST 2018; root:xnu-3248.73.5~1/RELEASE_X86_64 x86_64 i386

概述

最显著的几个结果：

• Time/op

以上结果与mux回归报告相符，但在tip上大约有5%的回归，因此总体来说：自Go1.10以来大约有15%的回归，自2fd1b52之前在tip上大约有10%的回归，至少在我的机器上是这样。

• Allocs/op

所有结果
[1] 在https://gist.github.com/odeke-em/3a6c95c4aa74d15619ab95728337e615上有完整的结果摘要。

好的，我刚刚发现了一个从CookieString中回归的错误，我们在这个提交中切换到了使用strings.Builder。提交代码为48db2c0#diff-44567335da7512324c74b50e5fcb3def,也被称为CL https://go-review.googlesource.com/102479。

对于CookieString,结果是疯狂的，无论是ns/op还是allocs/op都在增加，但allocs/op的增长更为剧烈，增加了40%。

之前

BenchmarkCookieString-4   	 1000000	      1055 ns/op	     384 B/op	       3 allocs/op

之后

BenchmarkCookieString-4   	 1000000	      1086 ns/op	     360 B/op	       5 allocs/op

虽然我认为Cookie.String并没有被广泛使用；但是对于那些记录每个请求的cookies的服务器来说，这是一个巨大的隐性成本。因此，我建议在Go1.11中回滚CookieString的更改。它在之前运行良好，而且我也不确定使用strings.Builder的更改是否提供了更好的可读性改进。请@bradfitz和@ianlancetaylor查看报告的CL。

@odeke-em,通过选择正确的strings.Builder预分配大小来修复了这样一个回归。请参阅CL113235。

@quasilyte 很好，但这需要一些专门的技能和审查 #LiamNeeson
然而，我不确定在net/http.Cookie.String中使用预分配是否直观，并且可以轻松地推理。

https://golang.org/cl/113996提到了这个问题：net/http: fix a few regressions since Go1.10