Python在设计上比编译语言慢——解释器、动态类型和垃圾收集增加了开销。但大多数Python性能问题不是”Python很慢”的问题——它们是算法效率低下、不必要的I/O或数据结构的错误使用，这些在任何语言中都会很慢。以下是修复的层次结构。
首先找到实际瓶颈
过早优化是Python项目中显著浪费的根源。在更改任何内容之前，先进行性能分析。`cProfile`（标准库）：`python -m cProfile -s cumulative myscript.py`显示每个函数花费的累积时间。`pstats`模块允许过滤。`line_profiler`：对你怀疑的函数进行逐行性能分析——用`pip install line-profiler`安装，用`@profile`装饰函数，用`kernprof -l myscript.py`运行。`memory_profiler`：按行的内存使用——当内存而不是CPU是瓶颈时很有用。`py-spy`：一个附加到正在运行的Python进程而无需重启的采样分析器——用于分析生产代码。实际洞察：在大多数情况下，90%以上的执行时间在5%的代码中。性能分析告诉你哪5%；优化其余的是浪费的努力。
算法和数据结构修复（最高影响）
O(n²) vs O(n log n) vs O(n)：对10,000个项目的列表进行嵌套循环运行1亿次迭代；对相同数据的字典查找运行10,000次查找。算法复杂度主导了硬件和语言速度差异。常见模式：使用`in list`（O(n)线性搜索）vs `in set`或`in dict`（O(1)哈希查找）。在重复成员测试之前将列表转换为集合通常是100倍的加速。避免在循环中反复追加字符串：Python字符串是不可变的——循环中的`result = result + new_string`每次迭代都会创建一个新的字符串对象。改用`””.join(list_of_strings)`。生成器表达式vs列表推导式：`sum(x**2 for x in range(1000000))`不会在内存中构建完整列表；`sum([x**2 for x in range(1000000)])`会。对于大型可迭代对象，生成器减少了峰值内存。`collections`模块：`Counter`用于频率计数，`defaultdict`避免键存在检查，`deque`用于O(1)从两端弹出/追加（list.pop(0)是O(n)）。Pandas向量化：如果你用Python`for`循环迭代DataFrame行，你做错了——使用向量化操作（`df[‘col’].apply(func)`，或者更好，对底层数组进行numpy操作）。在Python中迭代100万行vs numpy通常慢100到1000倍。
何时使用外部工具
NumPy：对于数值数组操作，NumPy在连续内存上运行编译的C代码——通常比纯Python循环快10到100倍。模型：将计算表达为数组操作，而不是Python循环。PyPy：一个JIT编译的Python解释器——对于CPU密集型纯Python代码，PyPy通常以零代码更改给出5到10倍的加速。不适合所有库（NumPy集成有效，但某些C扩展不行）。Cython：用类型注释将Python代码编译为C——对性能关键的内层循环很有用。需要编译步骤。多进程：Python的GIL阻止了CPU密集型工作的真正多线程。`multiprocessing.Pool`运行没有GIL限制的独立进程——对可并行化的CPU密集型任务很有用。`concurrent.futures.ThreadPoolExecutor`适用于I/O密集型任务（在I/O期间GIL被释放，线程可以正常工作）。asyncio：对于高并发的I/O密集型代码，asyncio允许在单个线程中进行数千个并发操作，而没有数千个线程的开销。`aiohttp`和`httpx`用于异步HTTP；`asyncpg`用于异步PostgreSQL。层次结构：首先修复算法；然后numpy/pandas向量化；然后multiprocessing/asyncio；只有这样才考虑Cython或PyPy。
