Python性能优化实战：从瓶颈定位到算法与并发加速-北京尧图网络

今天想聊一个几乎所有写 Python 的人都会碰到的话题——Python 性能优化。网上关于“Python 跑得慢”的段子一抓一大把但真正做开发的都知道大部分程序“卡成 PPT”并不是语言的问题而是写法、数据结构和方案选型出了问题。我见过不少线上服务明明 CPU 占用不高接口却老是超时也有同事写的脚本要跑一晚上才能出结果优化之后十几分钟搞定。问题不在别处就在代码本身。这篇文章我会沿着一条完整的优化路径走一遍:怎么用工具定位瓶颈、怎么从算法和数据结构上拿到最大增量、怎么写更快的代码细节、怎么用多进程和异步突破单核限制最后用 Numba 把纯 Python 循环压到接近 C 的速度。每一节都会有可直接抄的代码和参数适合所有写过一段时间 Python、开始对性能有要求的读者不管是写脚本、写爬虫、做数据处理还是写 Web 服务照着思路走基本能让代码上一个台阶。1. 性能优化不是玄学先找出瓶颈再动手我见过太多人一上来就改代码把 for 循环改成列表推导式把没用到的库删掉结果程序还是慢。为什么因为根本没找准痛点。性能优化的第一原则是没有测量一切讨论都是猜。先花十分钟定位热点往往能省下后面好几天的无效工作。1.1 用 cProfile 快速定位热点函数Python 自带的cProfile是性能分析里最趁手的工具不需要装任何第三方库。用起来很简单python -m cProfile -s cumulative your_script.py它会逐行统计每个函数的调用次数和耗时-s cumulative表示按累计耗时排序这样可以一眼看到“谁的总耗时最高”。实际输出里几个关键字段的意思是这样的字段含义怎么用ncalls调用次数次数高但单次耗时的函数可以考虑缓存结果tottime函数自身耗时不包含子调用排第一的就是“热点本体”cumtime累计耗时包含它调用的所有子函数排第一的多半是“入口层”filename:lineno文件名和行号直接定位到具体代码行读输出有个小技巧先把tottime高的函数圈出来这些是真正在“烧” CPU 的地方再看cumtime确认这个热点是怎么被调用链驱动起来的。比如你看到某个parse_line()的 tottime 特别高再往上翻发现是load_file()反复调它那优化方向就清楚了。如果直接改load_file()很可能是白忙活。用cProfile.run()也可以只分析一段代码不需要跑整个脚本import cProfile cProfile.run(main(), sortcumulative)有一点要提醒cProfile 本质是给每个函数调用挂统计钩子会显著拖慢程序尤其对 IO 密集或线程密集的程序测出来的数据和真实运行会有偏差。这时候可以用py-spy这类采样式 profiler它不干预程序运行直接 attach 到进程上采样调用栈更适合线上环境以后排查疑难杂症会用得上。1.2 用 timeit 做微基准测试别拿秒表骗自己定位到热点函数之后改完一个细节到底有没有变快需要用timeit来验证。它专治“感觉快了一点”——感觉这东西极不可靠尤其在代码从 0.5 秒变成 0.45 秒的情况下。import timeit setup import random data [random.random() for _ in range(100_000)] stmt sum(data) result timeit.timeit(stmt, setupsetup, number1000) print(result)number1000表示把sum(data)连续执行 1000 次取总时间。我一般会配合repeat参数res timeit.repeat(stmt, setupsetup, number1000, repeat5) print(min(res))为什么取min而不是平均值因为机器上总会有系统调度、其他进程抢占等干扰平均值容易被极端噪声带偏而最小值最接近“代码本身的真实耗时”。正常情况下单次测量应该让程序跑几十毫秒以上如果太快就增大number如果太慢就减小number。比如一个函数单次只要 0.01 毫秒number1000算下来才 10 毫秒噪声影响就很大我会调到number100_000。还需要注意perf_counter()、process_time()、time.time()这几个时间的区别。perf_counter是墙上时钟wall clock包含睡眠等待时间适合测真实耗时process_time只统计当前进程消耗的 CPU 时间不受 sleep 影响。要测一个 IO 密集任务到底“等了多少时间”用perf_counter要测一个计算任务“吃了多少 CPU”用process_time。用错了工具会得出完全相反的结论。2. 算法与数据结构性能的主要增量很多人迷信“微优化”觉得把循环改快一点、函数少调几次就能逆天改命。实际上绝大多数性能问题出在算法复杂度上。一个 O(n²) 的算法优化得再漂亮数据量上来之后照样拖垮机器换成 O(n log n) 的算法哪怕写得粗糙一些跑起来也轻松得多。2.1 复杂度选型数据结构决定了你能跑多快来做一个最经典的对比在列表里查找一个元素和在一个集合里查找一个元素。列表in操作的时间复杂度是 O(n)数据量大了线性扫描很耗时间集合底层是哈希表in操作均摊是 O(1)。我用 100 万个整数的列表和集合实测过列表的100_000 in my_list平均要扫五十万次而集合几乎瞬间返回。道理很直白列表像翻抽屉找东西运气不好要翻遍所有抽屉集合像有索引的档案柜根据编号直接翻到那一格。操作列表/元组集合/字典查找元素O(n)O(1)尾部插入O(1) 均摊O(1) 均摊任意位置插入O(n)不支持判断是否存在O(n)O(1)如果你有一个高频检查“某个 ID 是否存在”的需求第一反应就应该是集合而不是列表。判断“对象是否重复”也是这样seen set()几乎是万能解法。另外如果你需要在一个有序列表里反复插入并保持顺序不要自己写二分查找直接用bisect模块import bisect data [1, 3, 5, 7, 9] bisect.insort(data, 6) # data - [1, 3, 5, 6, 7, 9]bisect.insort的查找部分已经帮你优化好了底层用 C 实现比自己写的二分循环快。还有一个细节字典和集合的键要求可哈希。如果你用自定义对象做键必须同时实现__hash__和__eq__而且保证哈希值在对象生命周期内不变否则会出现“键放进去了却找不到”的诡异问题排查起来很头大。2.2 用缓存消灭重复计算lru_cache 是递归程序的神很多程序慢不是因为单次计算贵而是同一个结果被反复计算。最典型的例子就是递归求斐波那契数列def fib(n): if n 2: return n return fib(n - 1) fib(n - 2)不加缓存时fib(35)就要跑差不多一秒到fib(40)已经要好几秒调用次数呈指数爆炸。原因是同一个fib(20)会被重复调用无数次。加一个lru_cache装饰器问题直接解决from functools import lru_cache lru_cache(maxsize128) def fib(n): if n 2: return n return fib(n - 1) fib(n - 2)lru_cache会记住每个输入对应的输出后续调用直接命中缓存。maxsize是能缓存多少个结果这个参数怎么选如果函数入参组合有限、内存充足可以设大一些命中率更高如果入参组合非常多设太大容易让字典占满内存。我通常对递归函数设 128 或 256 就够对配置解析、价格查询这类低频函数可以设到 1024。注意maxsizeNone意味着不淘汰要谨慎使用避免无限增长。缓存思想不只适用于递归。爬虫里重复请求同一个 URL、数据处理里反复读取同一个文件、批量接口调用里反复解析同一段配置全部可以用缓存解决。工程实践上缓存的难点不是“用不用”而是“什么时候失效”。如果数据会更新记得给缓存加过期时间或者使用带失效机制的缓存库。2.3 从 O(n^2) 到 O(n)一次真实的改写看一个很常见的场景在一个数组里找两个数使它们的和等于目标值。很多人第一反应是双重循环def two_sum_naive(nums, target): for i in range(len(nums)): for j in range(i 1, len(nums)): if nums[i] nums[j] target: return [i, j]这个写法在几万个元素的数组上就会明显变慢。改用哈希表存“已经见过的值”一次遍历就搞定def two_sum(nums, target): seen {} for i, v in enumerate(nums): if target - v in seen: return [seen[target - v], i] seen[v] i return []第二个版本的时间复杂度是 O(n)空间复杂度也是 O(n)。这是典型的“空间换时间”用一份字典的代价换掉了整个内层循环。我在优化数据处理脚本时经常遇到类似的结构一个循环里套一个查找把查找换成哈希表整体耗时立刻下降一个数量级。写代码时只要闻到“循环套循环”的味道就要警惕是否能用哈希表或集合重写。当然空间换时间要有个度。如果一个 n 非常大的场景额外内存可能也要几百 MB这时候需要权衡是继续用 O(n²) 时间换取少量内存还是加内存换时间。没有银弹但大多数业务场景里单机上几百 MB 内存通常比几十秒 CPU 等待更不值得。3. 代码层级的微观优化小习惯差一大截算法和数据结构搞定了接下来才是抠代码细节。这些优化单个看都是几毫秒、几十微秒的收益但放在高频调用的热点路径上积少成多非常可观。这里说的都是常规文档里容易忽略但实际收益明显的点。3.1 局部变量绑定与内置函数的正确用法Python 的属性访问比如math.sqrt里的点号比局部变量访问慢很多因为点号背后是字典查找和方法解析。在循环里反复访问同一个属性等于每次都做一次查找。解决办法很简单在循环外把它绑定为局部变量。import math # 不推荐反复属性查找 for x in data: y math.sqrt(x) # 推荐先绑定再循环 sqrt math.sqrt for x in data: y sqrt(x)这个写法不是玄学实测在循环量大的情况下可以减少不少属性查找开销。同理len()、内置函数在 Python 3 中已经很快但如果你在一个超长循环里反复调用某个常用函数也可以先绑到局部变量上。不过不要走火入魔——只在热点路径里用普通代码保持可读性更重要。另外map、filter这类内置函数返回的是生成器对象本身不会立即执行计算只有迭代时才逐项产生结果。这意味着它们天然适合处理大数据流不会一次性把整个中间列表放进内存。但要注意如果后续操作必须拿到完整列表那你最终还是一样要付出列表化成本。判断标准很简单——下游需要逐项处理就用生成器需要反复随机访问就用列表。3.2 字符串拼接、列表推导式与生成器的选择字符串拼接是一个非常经典的性能陷阱。很多人习惯用循环拼字符串parts [a] * 100_000 s for p in parts: s p这个写法的问题在于字符串是不可变对象每次都会创建一个新字符串把旧内容复制一遍。数据量大了之后总复制量是 O(n²) 级别的。正确做法是用joins .join(parts)join一次遍历所有片段只需要一次分配。实测同样拼十万个短字符串join比快几十倍。这不是“尽量用”而是“必须用”。每次看到循环里拼字符串我都建议立刻改成join或列表收集后一次性拼接。列表推导式比手动append循环快这已经是常识了因为列表推导式底层走的是专门的字节码不用反复调用append方法。比如# 不推荐 result [] for x in data: if x % 2 0: result.append(x * x) # 推荐 result [x * x for x in data if x % 2 0]但要注意如果推导式里的表达式非常复杂甚至要调用一个耗时函数那收益会被计算本身淹没。还有一点生成器表达式(x * x for x in data)在内存上比列表推导式节省得多适合处理海量数据流但如果你的代码很快就要遍历多遍就老老实实用列表生成器只能遍历一次第二遍就得重建。3.3 标准库里的“性能加速器”排序、计数与迭代工具标准库里藏着不少常被忽略的性能利器。先说排序sorted(data, keyfunc)里的key参数非常关键它会让每个元素只调用一次func算出排序键而不是在比较时反复调用。如果你需要按对象的某个属性排序千万别写自定义比较函数直接用keylambda x: x.attribute差距在数据量大时很明显。再说计数。统计大量元素出现次数有人喜欢手动维护字典counts {} for x in data: counts[x] counts.get(x, 0) 1这个写法没错但collections.Counter更简洁from collections import Counter counts Counter(data)Counter本身是字典的子类底层和手动计数一样但代码更清晰。如果数据规模特别大还可以考虑用counts.update(batch)分批累加。itertools模块则提供了大量高性能迭代工具islice做切片不复制列表、chain拼接多个迭代器、groupby做分组处理。我经常用islice避免复制巨大的切片列表。举个例子对一百万条日志取前一百条from itertools import islice first_100 list(islice(log_lines, 100))如果不这样写直接log_lines[:100]会先把整个列表的切片逻辑跑一遍、分配新列表虽然结果一样但无谓开销不小。要警惕的是这一层的优化容易上瘾陷入“为了快而快”的误区。我的原则是先跑通功能再用 profiler 找到真实热点最后只对热点做微观优化。可读性是长期维护成本的一部分过度使用晦涩写法得不偿失。4. 并行与异步突破单核的瓶颈前面聊的都是单线程内的事再优化也有物理上限。如果程序仍然慢就该考虑让多核 CPU “同时干活”了。Python 的并行和异步向来是重灾区很多人分不清线程、进程和协程的适用场景一上来就开线程池结果 CPU 密集任务反而更慢。这一节把机制和选型一次讲清楚。4.1 先认清 GIL再决定用线程还是进程Python 解释器里有一把全局锁叫 GILGlobal Interpreter Lock它保证同一时刻只有一个线程能执行 Python 字节码。所以纯 CPU 密集型任务用多线程不仅不会更快还会因为线程切换开销变得更慢。真正的多核并行只能靠多进程实现。判断任务属于 CPU 密集还是 IO 密集有个很实用的观察方法运行程序时看 CPU 占用率和sleep状态。如果任务跑起来 CPU 立刻飙到 100% 以上大概率是计算密集如果任务大部分时间在等待网络响应、等待磁盘读取CPU 占用很低就是 IO 密集。IO 密集适合线程池或异步CPU 密集适合进程池。方案适用场景关键限制多线程 threading / ThreadPoolExecutorIO 密集网络、磁盘、数据库GIL 导致 CPU 密集无法并行多进程 multiprocessing / ProcessPoolExecutorCPU 密集进程间通信、Pickle 序列化开销异步 asyncio高并发网络 IO、事件驱动事件循环内不能有阻塞调用还有个经常被忽略的点Python 3.13 开始引入了实验性的自由线程模式free-threading可以真正去除 GIL但目前还属于新特性生态兼容性需要仔细验证。短期内在生产环境还得按传统方案选型。4.2 多进程池与任务切分的正确姿势用多进程做 CPU 密集任务最省事的入口是concurrent.futures.ProcessPoolExecutor。示例from concurrent.futures import ProcessPoolExecutor def cpu_heavy(n): return sum(i * i for i in range(n)) def main(): with ProcessPoolExecutor(max_workers4) as executor: results list(executor.map(cpu_heavy, range(8))) print(results)关于max_workers怎么选我一般先看机器核数os.cpu_count()能拿到逻辑核心数。但不要直接设满因为主进程本身也要做任务调度和数据收集系统还要跑其他程序。我通常设max_workersos.cpu_count() - 1或者按任务的 CPU 密集程度微调。极端情况下如果每个子进程内存占用很大还需要同时考虑内存上限。使用进程池有几个坑要特别留意。第一个坑是参数传递。进程池传递任务参数时要经过 Pickle 序列化如果传输的是很大的 DataFrame 或大对象序列化时间可能比计算本身还长。解决办法是把大对象放到共享内存、文件系统或数据库里传给子进程的只是文件路径或索引。第二个坑是异常处理。executor.map返回的结果是惰性生成的如果某个子任务抛了异常异常会在迭代到那个任务时才抛出不会在提交时立刻报错。最好用submitas_completed加try/except包住future.result()。from concurrent.futures import ProcessPoolExecutor, as_completed with ProcessPoolExecutor(max_workers4) as executor: futures [executor.submit(cpu_heavy, n) for n in range(8)] for fut in as_completed(futures): try: result fut.result() except Exception as e: print(任务失败:, e)第三个坑是 Windows 下的模块导入。在 Windows 上多进程会用spawn方式创建子进程它需要重新导入主模块。如果主代码直接写在顶层没有if __name__ __main__:保护子进程会在导入时无限递归创建新进程直接抛 RuntimeError。所以任何涉及多进程的脚本主执行逻辑都要包在if __name__ __main__:里。这个坑在 Jupyter Notebook 里尤其阴险直接在 Notebook 里跑ProcessPoolExecutor经常不工作建议先导出为.py文件再运行。4.3 异步IO把等待时间捡回来IO 密集场景比如要请求几百个 URL、查几百个数据库用asyncio效果非常显著。我用一个很直观的例子说明同步串行请求 200 个网页假设每个请求 0.3 秒总耗时 60 秒用asyncio并发拉起 50 个连接总耗时可能只有 6 秒。省下来的不是 CPU 时间而是并发等待的时间。一个简单的异步请求示例需要先pip install aiohttpimport asyncio import aiohttp async def fetch(url, session): async with session.get(url) as response: return response.status async def main(): urls [https://example.com] * 50 async with aiohttp.ClientSession() as session: tasks [fetch(url, session) for url in urls] results await asyncio.gather(*tasks) print(results) # asyncio.run(main())异步代码最关键的禁忌是在事件循环里调用阻塞函数。比如time.sleep(1)、同步的requests.get()、普通的文件读写这些阻塞调用会卡住整个事件循环让所有协程一起等待并发形同虚设。正确做法是使用异步版本await asyncio.sleep(1)、aiohttp.request或者把阻塞调用丢到线程池里。Python 3.9 之后提供了非常方便的asyncio.to_thread()import asyncio async def main(): result await asyncio.to_thread(sync_blocking_function, arg1)asyncio.to_thread会把阻塞任务放到默认线程池执行不阻塞事件循环。这个函数我从 3.9 开始就在用迁老代码时非常顺手。另外注意asyncio.gather多个任务时如果其中一个异常默认会立刻抛出并取消其余任务。想容错可以给 gather 加return_exceptionsTrue逐个检查返回结果——这段经验是从线上报警里学来的一个请求失败别让整批请求陪葬。5. 让代码飞起来的终极武器C扩展与运行时如果算法、数据结构、并行异步都优化完了还是有某个纯计算热点绕不开那就该考虑把热循环交给“编译型”的方案了。这不是让你立刻去学 C而是有现成的工具可以用最推荐的是 Numba。5.1 Numba一条装饰器获得编译级加速Numba 是一个 LLVM 编译器它能把被装饰的 Python 函数即时编译成机器码。用法出乎意料地简单加一个njit装饰器。注意要装一下pip install numba。我用蒙特卡洛模拟求圆周率来演示加速效果这个例子计算量大、逻辑简单最适合看对比。import numba import numpy as np numba.njit def monte_carlo_pi(n): hits 0 for _ in range(n): x np.random.random() y np.random.random() if x * x y * y 1.0: hits 1 return 4.0 * hits / n同样是n 100_000_000纯 Python 版本可能要四十秒加了njit之后基本一两秒内出结果加速比往往超过二十倍。为什么这么快因为njit默认走nopythonTrue路径整个函数从 Python 对象循环变成原生机器码循环不再有解释器的动态类型开销。它专治“数值计算循环”这种组合。有几个使用要点必须强调清楚。第一第一次调用会比较慢因为 JIT 要编译。编译耗时通常零点几秒到几秒看函数复杂度。解决方法是njit(cacheTrue)把编译结果缓存到磁盘下次启动直接加载省掉重复编译时间。第二njit不是所有 Python 语法都支持。它支持的是数值运算、NumPy 函数和基本控制流但动态类型、复杂闭包、某些字符串操作不支持。遇到不支持的代码Numba 会报错并告诉你是哪一段不适合这时候别硬掰把它挪出njit函数或者重构成支持的形式。实测下来凡是不支持的往往本身也不适合做热循环。第三不要在njit函数里调用不受支持的 Python 对象方法。比如list.append某些情况能支持但自定义类的属性和方法一般不支持。我一般只把纯计算部分丢进njitIO 和业务逻辑留在外面层层传数据进去。5.2 Cython与PyPy什么阶段才值得上Numba 解决的是“数值计算循环”如果热点是复杂的业务逻辑、字符串处理、或者需要深度控制内存布局那就要考虑 Cython 或 PyPy。Cython 的玩法是写一个.pyx文件在变量和函数上标注 C 类型然后编译成扩展模块。它能做到和手写 C 相当的性能但代价是引入了新的构建流程和类型标注维护成本明显上升。我的建议是只有当你已经把算法、数据结构、并行、Numba 都试过一遍并且瓶颈确实在 Python 对象操作本身时才值得上 Cython。很多团队项目生命周期里根本走不到这一步硬上 Cython 往往带来更多坑。PyPy 是另一个 Python 运行时自带 JIT可以不加代码就加速纯 Python 程序。但它对 C 扩展的兼容性是个大问题很多依赖比如 pandas、某些科学计算库在 PyPy 下要么没有预编译包要么性能反而更差。所以 PyPy 更适合长期运行的、纯 Python 写的数据分析或脚本任务。如果你决定试试 PyPy先在测试环境完整跑一遍现有测试用例确认所有依赖都兼容再谈性能。选型建议很简单默认路径是“算法优化 → Numba”Cython 是为算法库封装而生的PyPy 是为纯 Python 长跑任务准备的。不要一上来就把所有工具往项目里堆。5.3 实战案例文本相似度计算从7秒到0.2秒这里放一个我实际优化过的小项目案例可以串起前面所有方法。需求是对 1000 条文本两两计算相似度输出最相似的前 N 对。初版实现很直接双重循环自定义编辑距离函数。跑一次要 7.2 秒看着不算灾难但如果文本涨到一万条那就是几百秒没法接受。第一步先跑cProfile发现热点是两个地方内层循环里的edit_distance()函数以及字符串切片操作。瓶颈清楚了。第二步算法层优化编辑距离函数里有大量重复的len计算和二维数组初始化改用一行数组互相交换的滚动数组写法把空间从 O(n*m) 降为 O(n)速度也提升了一截。然后加了一个简单剪枝如果两段文本长度差超过阈值直接判定相似度为 0跳过编辑距离计算。这一步把 7.2 秒压到 2.1 秒。第三步把编辑距离函数包上njit(cacheTrue)再做同样 1000 条文本两两对比耗时直接掉到 0.35 秒左右。四舍五入整个优化过程相当于把原来跑几十秒级别的批量任务变成了“秒回”状态。这个案例最有价值的一点是我没有在一开始就引入 Numba而是先做算法和剪枝。为什么因为edit_distance在被njit处理前必须先写成支持纯数值运算的形式。先做算法优化不仅让 Python 版本变快也让 Numba 的编译更顺畅。顺序反过来的话你很可能在编译失败、语法不兼容的坑里绕半天最后还得回头重构。6. 常见性能问题与排查技巧实录这一节写点实战中踩过的坑。很多性能和“环境”有关不是代码本身的锅。6.1 环境问题找不到DLL、Python版本带来的性能差异在 Windows 上运行某些科学计算库启动时可能直接报“由于找不到 msvcp140.dll无法继续执行代码”。这通常是因为缺了 Microsoft Visual C Redistributable 运行库。这不是代码问题也不直接算性能问题但它会让你的程序根本跑不起来或者一直卡在初始化阶段。解决办法是去微软官网装最新的 Visual C Redistributable装完重启再跑。这个坑我见过很多次团队新同事在 Windows 上搭环境时几乎每季度都会碰到一次。另一个容易被忽略的性能差异是 Python 版本。Python 3.11 开始官方在解释器层面做了大量性能优化包括新的自适应字节码解释器常见任务比 Python 3.8 快约 20% 到 60%。我的经验是如果你还在用 3.8 或更老的版本迁移到最新的稳定版本身就是一次“免费优化”。当然升级前要在测试环境完整跑一遍测试用例重点确认第三方库的兼容性尤其是科学计算、异步框架这些重依赖。6.2 profile之后程序反而更慢正常吗正常非常正常。cProfile本身有开销它会记录每个函数的调用次数和耗时所以打着 profile 的程序会比正常跑慢不少。这不代表程序真的变慢了只说明测量工具在起作用。真正看的是耗时分布而不是绝对耗时。如果担心 profile 干扰太大改用采样式工具如py-spy它几乎不影响目标进程性能。还有一个无数人踩过的坑不要在生产环境的入口直接挂cProfile日志会被输出文件占满磁盘。6.3 常见性能问题速查表症状原因检查方法解决方案多线程 CPU 占用高但没提速GIL 限制 CPU 并行观察 CPU 使用率和线程数改多进程或换 Python 3.13 自由线程特性并验证兼容列表推导式很慢推导式内部调用了耗时函数用 timeit 分步对比把耗时函数结果先缓存到局部变量字符串循环拼接反复复制字符串用 cProfile 看字符串操作改用.join(parts)递归求 fibonacci 极慢没有缓存重复计算查看调用次数加lru_cache进程池提交大对象慢Pickle 序列化开销观察任务执行时间和提交耗时传文件路径或索引避免大对象穿池异步程序整体卡顿事件循环里存在阻塞调用在协程里打断点确认等待位置换成await asyncio.sleep()或asyncio.to_thread跑阻塞函数同一函数首次调用很慢Numba JIT 编译看首次调用日志加cacheTrue预热这张表是我日常排查问题时的“默认菜单”大部分性能投诉都能对上其中一行。另外还有一个容易忽略的维度是内存性能瓶颈有时是内存分配太多、GC 频繁触发。可以使用memory_profiler或 tracemalloc 定位内存热点。一个典型场景循环里频繁创建大列表导致 GC 频繁执行CPU 全耗在回收上了。解决方法是用生成器替代中间列表或者复用已有的对象。6.4 我把基准测试写进回归测试的一个小经验最后分享一个我坚持了很久的小习惯性能优化完成后把基准测试变成回归测试的一部分。做法不复杂比如优化完某个函数后我会在项目里保留一个benchmark.py用pytest配合timeit写一条用例断言这个函数的耗时必须低于某个阈值。阈值留 30% 的余量避免 CI 环境抖动导致误报。import timeit def test_hot_function_performance(): stmt hot_function(data) elapsed timeit.repeat(stmt, setupfrom module import hot_function, data, number10, repeat3) assert min(elapsed) 5.0 # 阈值单位秒为什么这么做因为我见过太多“改着改着性能又回去了”的情况。重构、加需求、换依赖某个不经意的改动可能让之前的优化功亏一篑。基准测试就像一张性能“网”能在合入代码前就拦住明显的性能回退。说夸张点性能优化不只是某一次的动作更应该是一种“代码习惯”。每次写完一段关键代码顺手跑一句 timeit记录一份基线每次改动涉及热点路径时对比一下数字再合并。这样你的代码库会一直往更快、更稳的方向走而不是陷入“优化一次、退化半年”的循环。

Python性能优化实战：从瓶颈定位到算法与并发加速

相关推荐

MRAM+PIC18实现工业级掉电存储：SPI驱动与数据保护实践

阿里云ESA隐藏NAS端口：免端口域名访问完整方案

C# WinForm集成Sherlock实现三维模型与实时数据联动

更多资讯

Open SWE扩展层实战：用TaoToken统一Key打通自定义工具集成与DSL扩展开发

【Agent Harness】给模型厂商的一封信：求求你们，教教AI说“JSON-LD”吧——用TaoToken统一Key实测IRI补全

agents.md 实战：用 TaoToken 统一 Key 打通多 AI 工具配置

模拟QQ登录窗口：前端三件套练手项目详解

C# Winform Socket通信实战：TcpListener多客户端接入与心跳断线重连

C# Winform实现HTTP POST提交JSON并解析响应完整指南

今日更新

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？