我应该在部署时生成 *.pyc 文件吗？答案

【问题标题】：Should I generate *.pyc files when deploying?我应该在部署时生成 *.pyc 文件吗？
【发布时间】：2016-06-07 16:30:19
【问题描述】：

当开发 Python Web 应用程序 (Flask/uWSGI) 并在我的本地机器上运行它时，*.pyc 文件由解释器生成。我的理解是这些编译后的文件可以让事情加载更快，但不一定运行更快。

当我将同一个应用程序部署到生产环境时，它在一个对本地文件系统没有写入权限的用户帐户下运行。没有*.pyc 文件提交到源代码控制，并且在部署期间不努力生成它们。即使 Python 想在运行时写一个.pyc 文件，它也做不到。

最近我开始怀疑这是否对应用程序的性能有任何切实的影响，无论是在流程开始后的第一次浏览量方面，还是在其整个生命周期内始终如一。

我应该将python -m compileall 作为我的部署脚本的一部分吗？

【问题讨论】：

在我看来，部署它完全是愚蠢的，但你可以做到，因为 Python 必须转换为 bytecode 才能被解释，保留 .pyc 文件会有所帮助加快执行速度，因为你不必重新编译，在这里阅读这个也许会有所帮助*.com/questions/11368304/…
另一方面，如果你有一个长时间运行的应用程序，比如 Flask，它只会减少启动时间。 Flask 在运行时很少会加载模块。

【解决方案1】：

当然，您可以继续预编译到 .pyc，因为它不会造成任何伤害。

它会影响第一个或第 n 个页面加载吗？假设 Flask/WSGI 作为一个持久进程运行，一点也不。在请求第一页时，所有 Python 模块都已经加载到内存中（作为字节码）。因此，服务器启动时间将是唯一受未预编译文件影响的因素。

但是，如果出于某种原因为每个页面请求调用了一个新的 Python 进程，那么是的，性能上（可能）会有显着差异，并且最好进行预编译。

正如 Klaus 在上面的 cmets 中所说，页面加载可能受到影响的唯一其他时间是，如果函数碰巧尝试导入尚未导入的模块。这将要求模块被解析并转换为字节码，然后加载到内存中，然后才能继续。

【讨论】：

我只想说明“它不会受到伤害”的情况是不正确的：它不适用于使用 venusian 的项目，例如金字塔。 Venusian 完全忽略了 pyc/pyo 文件，这些文件至少会使每个金字塔应用程序都无法运行（这甚至是一个词吗？）。