pytest需要10分钟才能在内置编译方法中收集

Question

我有一个包含大约1800个测试的pytest测试套件，收集和执行这些测试需要10分钟以上的时间。我尝试在测试中创建一个cprofile，发现大部分时间，大约300秒在{built-in method builtins.compile}中，还有一些其他的正则表达式包中的编译方法调用，我试图删除这些调用，发现减少了大约50秒。但它仍然需要9.5分钟，这是很大的。

到目前为止，我所理解的是，内置的编译方法用于将脚本转换为代码对象，pytest内部使用此函数来创建和执行代码对象。但是对于运行1800个测试来说，9-10分钟的时间实在是太长了。我是pytest和python的新手，所以我想找出这个时候的原因。

有没有可能是pytest没有正确配置，它使用了编译方法来生成代码对象？或者其他导入的库可以在内部使用编译吗？

Answer 1

有没有可能没有正确配置pytest，它使用编译方法生成代码对象？

尽管我从来没有看过，但我完全希望pytest能够手动将文件转换为字节码，原因很简单，it performs assertion rewriting by default in order to instrument assert statements：当断言失败时，pytest将显示各种中间值，而不仅仅是显示断言消息。这需要以任何一种方式编译:要么将代码编译为字节码并重写字节码，要么将代码解析为AST，更新AST，然后仍编译为字节码。

可以禁用此行为(--assert=plain)，但我不希望从中获得太多好处(尽管我可能错了)：pytest只是这样做，而不是解释器自己执行编译。它必须以某种方式完成，测试套件才能运行。

虽然花5分钟听起来确实很多，但你是否有大量非常小的文件或其他东西？粗略的基准测试表明，在我的机器上，compile以大约5usec/行的速度工作(尽管这可能取决于代码的复杂性)。我有价值6kLOC的测试，虽然测试套件需要很长时间，但这是因为测试本身很昂贵，所以收集起来并不明显。

当然，你也有可能在pytest中触发某种边缘情况或问题，例如，也许你有大量的assert语句，这会导致pytest生成大量的重写代码？前面提到的--assert=plain可以暗示这一点，如果它使运行测试套件的时间大大缩短。

您也可以尝试运行--collect-only来查看结果，尽管我不知道断言重写是在收集过程中还是在收集之后执行的。在上面的6kLOC测试套件上，我在1.32秒内收集了216个测试。

无论哪种方式，这似乎更适合pytest bug追踪器。

，或者其他导入的库可以在内部使用编译吗？

您可以使用基于flamegraph的分析器来记录整个堆栈。坦率地说，cprofile是一堆狗屎。