是的。 几周前，我也将默认的 automl 停止标准更改为max_batches=1 ，但这没有帮助。

我喜欢你列出的解决方案！ 加上我自己的一个：

1. 在笔记本中添加一些隐藏代码，以跳过长时间运行的计算。 这可能是模拟管道拟合/预测的代码。 优点：有效。 缺点：可能与用户手动运行时得到的不匹配，加上隐藏的代码令人困惑。
2. 对于长时间运行的笔记本，在本地预运行一次并将输出保存在笔记本中。 如果存在，Nbsphinx 将使用保存的执行而不是重新运行。 优点：有效。 缺点：我们可能会忘记定期更新输出。
3. 简化/删除部分笔记本内容。 例如，如果可能，考虑降低数据大小、停止标准等。 优点：加速。 缺点：无法显示某些示例的完整输出，例如文本。

我建议我们选择选项 2，但要记住选项 3。

1627 已作为副本关闭，但我认为仍有一些内容未包含在此问题中，因此请在此处发布：

我注意到文档的构建时间要长得多。 我认为这可能是因为在 c871f3b 中更改了 automl 文档以使用欺诈数据集，而不是乳腺癌数据集（+ 其他地方？）来展示 infer_problem_types，因为乳腺癌数据集只有数字列。

我怀疑这是文档构建时间更长的不同问题/原因，从之前的 20 分钟到现在> 30 分钟，值得一提！

@dsherry仅供参考

另一种可能的解决方案是使用多个处理器来构建文档：

https://www.sphinx-doc.org/en/master/man/sphinx-build.html#cmdoption -sphinx-build-j

更新以下与@dsherry 的讨论。

添加在-j标志，我们的Makefile使build docs上circleci测试完成速度更快，因为看到这里。 不幸的是，ReadtheDocs 不运行此命令，这意味着实际生成已发布文档仍然需要一段时间，并且经常会出错。

这就是 ReadtheDocs 成功构建的样子，需要 20 多分钟才能完成。 HTML 和 Latex 构建时间之间的差异表明构建 Jupyter Notebook 本身不需要很多时间，这很好。

但是，我们也发现当所构建失败像这样。 我们注意到，出于某种原因，ReadtheDocs 运行了两次完整的命令序列，这导致构建需要更长的时间（创建 HTML 和 Latex 文件每个都超过 30 分钟），并导致 doc 构建失败。 我将与 ReadtheDocs 支持团队进行跟进，以了解发生这种情况的原因以及我们如何解决此问题，当我收到反馈时，我将在此处更新这些结果。

@bchen1116联系了支持，他们说

看起来此错误的根本原因是您拥有的活动版本数。 我在我们的日志中看到了一些与此相关的错误。
要暂时解决此问题，您可以减少保留的活动版本的数量。 看起来您正在为单个分支或拉取请求构建版本，您是否尝试过我们的拉取请求构建功能？ 这将有助于在构建后删除不需要的版本，同时仍保留构建的内容。

我相信这里引用的“拉取请求构建功能”就是这个，确认。

更新：
我们已将 RTD 更新为仅从拉取请求构建，删除了对我们推送的不同版本（分支）的不必要构建。 此外，我们已经从 RTD（我们用于 PR 的杂项分支）中删除了所有不必要的（未标记的）版本，这似乎有助于文档构建。 我们没有注意到构建中的任何文档超时，因此我们将在明天关闭此问题，除非我们再次开始看到超时。

@bchen1116现在可以关闭了吗？

现在关闭，因为缓慢的文档构建没有问题。