Python 程序变慢时，多数人第一反应是改写循环或换框架，但缺乏数据支撑的改动常常事倍功半。合理的性能优化应当从测量开始，先弄清楚时间到底耗在哪里，再决定从算法、内存还是解释器层面入手。
一、先做性能剖析而非猜测
性能优化的第一步永远是 profiling，也就是用工具收集程序运行时的函数级耗时数据。Python 标准库中的 cProfile 是最常用的CPU耗时分析器，它能记录每个函数的调用次数、总耗时以及单次平均耗时，帮助开发者快速识别出所谓的“热点函数”。
下面这段示例展示如何用 cProfile 对一个简单计算任务进行剖析，并将结果按累计时间排序输出：
import cProfile
import pstats
def heavy_task():
# 模拟一个计算密集型的嵌套循环
total = 0
for i in range(10000):
for j in range(1000):
total += i * j
return total
if __name__ == '__main__':
profiler = cProfile.Profile()
profiler.enable()
heavy_task()
profiler.disable()
stats = pstats.Stats(profiler).sort_stats('cumtime')
stats.print_stats(10)
从输出中可以看到 heavy_task 占据了几乎全部运行时间，这时再去审视其中的双重循环才有意义。如果没有这一步，盲目优化其他只占用毫秒级的辅助函数，对整体性能几乎没有改善。
除了 cProfile，line_profiler 能精确到每一行代码的耗时，memory_profiler 则用于观察内存增长。根据瓶颈类型选择工具，才能避免用错优化手段。
二、算法与数据结构层面的优化
当 profiling 指出某个函数耗时极高，第一步应检查算法复杂度。比如在列表中频繁做成员判断，时间复杂度是 O(n)，改用集合后降为 O(1)。这类改动不依赖任何第三方库，却常常带来数量级的提升。
以下代码对比了列表查找与集合查找在十万次查询下的差异：
import time
def query_with_list(data, targets):
# 每次 in 操作都要遍历整个列表
return [t for t in targets if t in data]
def query_with_set(data, targets):
# 转换为集合后，in 操作接近常数时间
data_set = set(data)
return [t for t in targets if t in data_set]
if __name__ == '__main__':
base = list(range(100000))
to_find = list(range(0, 100000, 10))
start = time.time()
query_with_list(base, to_find)
print('list cost:', time.time() - start)
start = time.time()
query_with_set(base, to_find)
print('set cost:', time.time() - start)
在数据量较大时，集合版本通常比列表版本快几十倍甚至更多。需要注意的是，将列表转为集合本身有开销，如果只做一两次查询，未必划算，因此要结合调用频率来判断。
另外，字典替代频繁的条件分支、使用 deque 处理队列头部操作、避免重复排序等，都属于这一层的优化。它们不改变语言运行机制，却直接降低时间复杂度。
三、减少对象创建与利用生成器
Python 中一切皆对象，频繁创建临时对象会给垃圾回收带来压力。在循环里拼接字符串、反复生成大列表，都会放大内存与 CPU 开销。此时可优先考虑生成器，按需产出数据而非一次性占满内存。
下面示例展示用列表和生成器处理大文件行的不同内存表现：
def read_lines_list(path):
# 一次性读入所有行，占用大量内存
with open(path, 'r', encoding='utf-8') as f:
return f.readlines()
def read_lines_gen(path):
# 逐行产出，内存占用稳定
with open(path, 'r', encoding='utf-8') as f:
for line in f:
yield line.strip()
if __name__ == '__main__':
# 假设存在一个大文本文件 data.txt
for line in read_lines_gen('data.txt'):
pass
对于百万行级别的文件，生成器版本的内存占用可以维持在极低水平，而列表版本可能直接触发交换分区。在数据处理管道中，用生成器串联多个步骤，还能避免中间结果落地。
字符串拼接方面，使用 join 而非加号累积，也能减少中间字符串对象的产生。这些细节单独看微不足道，在高频循环中却会成为明显瓶颈。
四、将密集计算交给底层扩展
当纯 Python 代码已经过算法优化，仍存在大量数值运算时，应当考虑将热点移交给 C 层面。NumPy 通过向量化操作避免了 Python 层循环，Cython 可将关键函数编译为扩展模块，multiprocessing 则绕过全局解释器锁利用多核。
以下示例用 NumPy 替代前面的双重循环累加：
import numpy as np
def numpy_task():
# 用外积一次性计算矩阵并求和，避免 Python 层嵌套循环
i = np.arange(10000)
j = np.arange(1000)
matrix = np.outer(i, j)
return matrix.sum()
if __name__ == '__main__':
result = numpy_task()
print(result)
NumPy 的底层用 C 实现，对大数组的运算速度通常比纯 Python 快两个数量级。但要注意，小数组或因频繁在 Python 与 NumPy 之间转换数据带来的开销，可能抵消其优势。
对于无法向量化的逻辑，Cython 或 ctypes 调用自写 C 函数也是可行路径。如果任务天然独立，用 multiprocessing 启动多个进程并行处理，能有效绕开全局解释器锁的限制。
五、理解全局解释器锁的影响
CPython 的全局解释器锁（GIL）导致同一进程内只有一个线程能执行字节码，因此多线程在 CPU 密集型任务中无法利用多核，反而因线程切换带来额外成本。很多初学者写了多线程爬虫或计算程序，却发现速度没提升甚至变慢，原因就在于此。
面对 CPU 密集场景，应优先选择多进程而非多线程；而 I/O 密集场景，如网络请求、文件读写，多线程仍具价值，因为等待 I/O 时会释放 GIL。以下示例展示多进程并行求和：
from multiprocessing import Pool
def partial_sum(n):
return sum(i * i for i in range(n))
if __name__ == '__main__':
with Pool(4) as p:
results = p.map(partial_sum, [1000000, 1000000, 1000000, 1000000])
print(sum(results))
该写法在四核机器上可将计算时间大致压缩到原来的四分之一。但进程间通信成本高于线程，数据量极大时需谨慎设计任务拆分粒度。
理清 GIL 的适用范围，才不会在错误场景投入无效并发改造。性能优化始终要建立在对运行时机制的准确理解之上。
六、建立持续测量的优化习惯
优化不是一次性动作。每次改动后都应重新跑 profiling，确认热点确实转移或消除，同时留意是否引入了新的瓶颈。用 pytest-benchmark 等工具固化性能测试，能在后续迭代中防止回归。
把测量、定位、改造、验证作为固定循环，比追逐某个“万能提速技巧”更可靠。Python 性能优化的入手点，永远是先让数据告诉你时间去了哪里。