Python很慢和/或它不是的两个最常见的原因高性能：

解读
GIL
第一个是相当直接的，但在高级别编译器将更高级别的语言翻译成更低级别（更快）的语言，因此编译语言几乎总是比非编译语言执行得更快。这个经验法则有一些例外（例如JIT可能比AOT编译更快的情况），但它们会分散讨论。

第二个是更臭名昭着，但是Python有一个叫做全局解释器锁的东西，它通过强制解释器一次只在一个进程（Python解释器的实例）中执行单个线程来基本上防止多线程。它的工作原理也很有趣，但也像编译器一样切入兔子洞。

Python性能下降9/10倍并不重要。

随着时间的推移，我认为有两个主要原因。

首先，重要的不是代码执行时间，而是最终用户体验。它不一般的问题，如果一个函数具有0.001秒或0.01来执行。在这种情况下，对于大多数问题，可以使用水平扩展来解决Python创建的许多瓶颈。

以这些基准为例对于流行的Web框架。使用Python的最好的是650.5K req / s，而最好的数字是2.2M。纯粹从性能的角度来看，你可能想知道为什么你不会选择最快的，但是你看看那个＃1点并意识到它正在使用C. C是一种很棒的语言（IMO），但是Python很多更具表现力，拥有更大的生态系统，您可以选择使用预先构建的工具。因此，在牺牲开发时间/范围的同时，不是从服务器中挤出最后一点计算能力，而是可以为每1个需要C的服务器获得4台Python服务器，并节省开发人员生产力和开发时间的许多倍。这显然是一个戏剧性和极其简化的例子，但我认为这一点是合理的。

这让我们围绕GIL的第二个实现和我的结论，它确实并没有那么糟糕。

通过不允许多线程（或在同一进程中同时执行），Python大大简化了开发人员面临的编程复杂性。 开发人员可以忽略多线程进程的常见 问题和优化，因为Python解释器一次只能执行一个逻辑。

这也通常不会多大关系为同一水平推理点1而不是解决与多线程问题，您可以选择与解决问题的多重处理。您可以启动多个进程并在它们之间进行通信，而不是在单个进程中管理多个线程。差异很微妙，但同样，对于这些情况中的9/10，多处理与线程的性能开销并不重要。

在头顶性能的情况下做的事情，你可以随时“胶水”不同的语言为你的Python逻辑。典型的例子是Numpy如何通过放入C将高性能数组结构数据结构带到Python。

那么这一切又是什么呢？

随着计算能力（处理器核心的数量，单个核心的速度，服务器硬件的成本等）越来越便宜，大多数性能问题通常可以通过水平扩展来解决。

对于你无法横向解决的事情，你可以用不同的语言写一些东西并将其“粘合”到你的Python逻辑中（假设Python是一种“胶水”语言）。

因此，如果最终可以增强/处理性能，那么您需要将Python作为一种语言的主要原因：

简单
生产的
可读（从而更易于维护）

关于Python的优点和缺点，我们可以谈论更多的内容，我们可以更详细地讨论，但我认为这是解决为什么Python解释器性能不会影响其受欢迎程度的问题的良好开端。