我将 #35852 作为提案，尝试描述这个问题并提出解决方案，但由于被拒绝，我退回到仅提交关于这个问题的 issue。解决方案被拒绝并不意味着问题不存在。
我们可以有在 godoc 中出现但不可运行的例子，以及作为 go test 一部分可运行的例子。这对于大多数用例来说已经足够了。
然而，假设在一个包中有多个示例，每个示例都需要花费非平凡的时间来运行，例如 200ms。由于它们无法与自身或其他在同一包内的测试并行运行，go test 可能需要比实际需要多几秒钟的时间。
问题的根本在于没有办法编写满足以下条件的例子：
- 是文档的一部分(即 godoc)
- 可运行(即在 godoc.org 上，或通过
go test运行) - 可扩展(即可以并行运行)
以下是我考虑的一些解决方法：
- 将一些示例重写为测试。不好，因为它们会在 godoc 中丢失，并对用户隐藏。失去点 1。
- 将示例拆分到多个包中。这使得
go test ./...更快，因为在测试的包之间存在内置的并行性。然而，这会拆分 godoc 页面，并且在一个包中有超过一小部分示例并不是不合理的。失去点 1。 - 使一些示例不可运行。也许是今天最好的选择，但仍然不是很好。一个可运行的例子总是由
go test验证，用户更容易看到它做了什么以及如何运行它。失去点 2。
在上面的提案中，我尝试探索了一些解决方案，以允许并行运行示例。我们是否可以探讨其他解决方案？
/cc @bcmills@leitzler@rsc
2条答案
按热度按时间rqqzpn5f1#
示例必须串行运行。但是，也许示例可以与测试并发运行？
这肯定会破坏某人的测试。
但是，如果有RunExamples和RunTests(我猜你需要RunBenchmarks),那么人们可以启动两个goroutine,一个用于示例，一个用于测试。
qgzx9mmu2#
也许 -这是一个有趣的想法。它不会很好地扩展，但它会比我们现在的要好得多。顺便说一下，我不仅仅关注如何使当前的方法更快。这就是我尝试过被拒绝的提案。例如：也许我们应该有一个全新的标准方法来提供示例代码或包，当它们太慢或复杂到无法直接作为可运行的示例时。成为标准是很重要的，因为你希望软件像
godoc一样向用户展示。