我们使用编译后的代码分发给无法访问源代码的用户。基本上是为了防止没有经验的程序员在没有告诉我们的情况下意外地更改某些内容或修复错误。

是的，性能是主要原因，据我所知，也是唯一的原因。

如果您的一些文件没有被编译，可能是因为目录权限或其他原因，Python无法写入.pyc文件。或者可能未编译的文件从来没有被加载……(脚本/模块只有在第一次加载时才会被编译)

运行编译过的python时性能有所提高。然而，当你将.py文件作为导入模块运行时，python将编译并存储它，只要.py文件没有改变，它将始终使用编译后的版本。

对于任何语言，当文件被使用时，过程看起来像这样: 1. 文件由interpeter处理。 2. 文件已编译 3.执行已编译的代码。

显然，通过使用预编译代码，你可以省去第2步，这适用于python, PHP和其他。

这里有一篇有趣的博客文章解释了它们的区别http://julipedia.blogspot.com/2004/07/compiled-vs-interpreted-languages.html 这里有一个解释Python编译过程的条目http://effbot.org/zone/python-compile.htm

没有涉及到的是源到源的编译。例如，nuitka将Python代码转换为C/ c++，并将其编译为直接在CPU上运行的二进制代码，而不是在较慢的虚拟机上运行的Python字节码。

这可以显著提高速度，或者当您的环境依赖于C/ c++代码时，它可以让您使用Python。

在运行编译脚本时，肯定会有性能差异。如果运行普通的.py脚本，每次运行时机器都会编译它，这需要时间。在现代机器上，这几乎不明显，但随着脚本的增长，这可能会成为一个更大的问题。

优点:

第一:温和的、可克服的困惑。

第二:如果编译生成的文件明显更小，那么加载时间就会更快。对网络来说很不错。

第三:Python可以跳过编译步骤。在初始负载时更快。这对CPU和网络来说都是好事。

第四:注释越多，.pyc或.pyo文件与源.py文件相比就越小。

第五:只有.pyc或.pyo文件的最终用户不太可能向您提供由他们忘记告诉您的未恢复更改引起的错误。

第六:如果您的目标是嵌入式系统，请获得较小的尺寸 要嵌入的文件可能代表着一个显著的优点，而且架构是稳定的，所以缺点之一(下面详细说明)没有发挥作用。

顶层编译

知道你可以用这种方式将顶级python源文件编译成.pyc文件是很有用的:

python -m py_compile myscript.py

这将删除注释。它保持文档字符串完整。如果你也想摆脱文档字符串(你可能想认真考虑为什么要这样做)，那么就用这种方式编译…

python -OO -m py_compile myscript.py

.．.你会得到一个。pyo文件而不是。pyc文件;就代码的基本功能而言，它具有同样的可分发性，但从剥离出来的文档字符串的大小来看更小(如果一开始就有像样的文档字符串，那么后续的工作就不那么容易理解)。但请看下面的缺点三。

请注意，python使用。py文件的日期，如果它存在，来决定是否应该执行.py文件而不是.pyc或.pyo文件——所以编辑你的.py文件，.pyc或.pyo将被淘汰，你所获得的任何好处都将失去。您需要重新编译它，以便再次获得.pyc或.pyo的好处。

缺点:

首先:在.pyc和.pyo文件中有一个“神奇的cookie”，它指示编译python文件的系统体系结构。如果您将其中一个文件分发到不同类型的环境中，它就会崩溃。如果你分发的.pyc或.pyo没有相关的.py来重新编译或修改，因此它取代了.pyc或.pyo，最终用户也无法修复它。

第二:如果使用如上所述的-OO命令行选项跳过文档字符串，则没有人能够获得该信息，这可能会使代码的使用更加困难(或不可能)。

第三:Python的-OO选项也根据-O命令行选项实现了一些优化;这可能会导致操作上的变化。已知的优化有:

Sys.flags.optimize = 1 Assert语句被跳过 __debug__ = False

第四:如果你故意让你的python脚本使用#!/usr/bin/python在第一行，这将被剥离到.pyc和.pyo文件中，该功能将丢失。

第五:使用选项-O和-OO，断言语句不会被编译，从而消除了运行时验证的来源。您可以使用try except来弥补这一点，但这需要放弃assert语句，以便在将要编译的任何内容中使用。

第六:有些明显，但如果你编译你的代码，不仅它的使用会受到影响，而且其他人从你的工作中学习的潜力也会减少，通常是严重的。