【发布时间】：2020-11-12 17:36:12
【问题描述】：
我想知道将__pycache__ 文件夹和.pyc 文件保存在内置容器中是好是坏。
一方面您希望最小化容器的大小，但另一方面您也不希望减慢容器的执行速度。
考虑到 python 解释器是静态的，这些文件也可以被认为是静态的。
有人做过一些性能测试并得出结论吗？
【问题讨论】：
标签： python containers pyc
【发布时间】：2020-11-12 17:36:12
【问题描述】：
就我个人而言，如果可能的话，我不会在容器中使用__pycache__/.pyc 文件。更具体地说，我尝试构建和运行我的容器，以便它们永远生成.pyc文件（设置环境变量PYTHONDONTWRITEBYTECODE=1并将--no-compile --no-cache-dir明确地传递给所有pip调用，或通过pip.conf 或等效的环境变量），无论是在构建期间还是在运行时。
缓存字节码的优势在于启动时间，而不是执行速度； import 需要更长的时间，但实际执行速度一样快（字节码仍在内存中，只是不在磁盘上）。但是在容器的情况下，使容器更大意味着缓存和启动需要更长的时间，因此您正在浪费磁盘空间，并且 Python 启动时间的任何收益通常会被延迟拉动和启动容器所抵消。在运行时写出字节码是没有意义的；当容器关闭时它会丢失，因此它会增加启动成本而没有任何好处。
拥有用于 Python 本身的基本安装的 .pyc 文件并不是那么糟糕（尽管如 cmets 中所述，官方 Dockerfiles 删除了它们）；由于有许多容器依赖于它们，因此基本 Python 映像已经被缓存的几率很高，并且许多预构建的 Python 映像已经拥有它们（因此事后删除它们无济于事），并且确实减少了启动时间对于在基于它们构建的容器中运行的程序有一点点。但是对于每个容器的第三方安装，您只会变得臃肿而没有任何补偿。
【讨论】：
-
official Python Dockerfiles expunge pyc 也
-
@BradSolomon：说得好。我有时会基于不太官方的 Python
Dockerfiles 来构建容器，但它们并没有这样做，显然，如果他们不这样做，如果你依赖它们，那么修复它就为时已晚，但是是的，如果可能的话，最好根本没有。