前几天调试程序，发现 QPS 总是卡在 20 左右上不去。开始以为是 IO 问题，就多开了些并发，然并卵，这才想到可能是 CPU 的问题。看了看监控，发现程序某一步的延迟在 400ms 左右，而且这一步是 CPU 密集的。当时开了 4 台双核的机器：(1s / 400ms) * 2 * 4 = 20 啊。看来需要优化下这一步的代码了，那么第一步就是找到可以优化的地方
测量程序的性能之前并没有实际做过，Google 了一番，感觉标准库的 cProfile 似乎值得一试。
要测量的代码逻辑也很简单，使用 lxml 解析 HTML，然后提取一些字段出来，这些基本都是调用的 C 库了，解析的算法也不在 Python 中。看起来似乎没有什么能改进的地方，不管怎样，还是先跑一下吧。
cProfile 有多种调用方法，可以直接从命令行调用：
python -m cProfile -s tottime your_program.py
其中的 -s 的意思是 sort。常用的 sort 类型有两个：
- tottime，指的是函数本身的运行时间，扣除了子函数的运行时间
- cumtime，指的是函数的累计运行时间，包含了子函数的运行时间
要获得对程序性能的全面理解，经常需要两个指标都看一下。
不过在这里，我们并不能直接使用命令行方式调用，因为我的代码中还需要一些比较繁重的配置加载，如果把这部分时间算进去了，多少有些干扰，那么我们也可以直接在代码中调用 cProfile。
使用 cProfile 的代码如下：
import cProfile, pstats, io pr = cProfile.Profile() pr.enable() extractor.extract(crawl_doc=doc, composition=PageComposition.row, rule=rule) pr.disable() s = io.StringIO()sortby = "cumtime" # 仅适用于 3.6, 3.7 把这里改成常量了 ps = pstats.Stats(pr, stream=s).sort_stats(sortby) ps.print_stats() print(s.getvalue())
把需要 profile 的代码放到 pr.enable 和 pr.disable 中间就好了。注意这里我们使用了 cumtime 排序，也就是累计运行时间。
结果如下：
我们可以看到总的运行时间是 200ms，而其中红框内的部分就占了 100ms! 如果能够优化调的话，性能一下子就能提高一倍。红框内的代码是做什么的呢？我们知道解析一个 html 文档，第一步是建立 DOM 树，通常情况下，我们可能会从其中抽取一些链接。在网页中，链接不一定是绝对路径，也可能是 /images/2018-12-31-xxx.jpg 这样的相对路径。lxml 库帮我们做了一个贴心的默认值，那就是在构造 DOM 树的时候，根据传入的 url 来吧页面中的所有 url 都重写成绝对路径。看起来这是个很贴心的功能，但是在这里却成了性能瓶颈。为什么很耗时呢？大概是因为需要遍历整个 DOM 树，重写所有的链接吧。这显然不是我们需要的，我们只需要把抽取之后的链接还原成绝对路径就好了，而不是事先把所有链接都重写一遍。所以在这里我们直接去掉这个功能就好了。
修改代码之后，再次运行 profile 脚本，时长变成了 100ms：
这时候我们接着看，程序中下一个比较大头的时间占用：jsonfinder 和 json decode/encode。
jsonfinder 是一个有意思的库，它自动从 HTML 中查找 json 字符串并尝试解析，但是有时候也不太准。经常为了找到特定的值，还是需要使用正则。那么对于这个可有可无的功能，性能有这么差，还是删掉好了。
通过删代码，现在性能已经是原来的四倍了。
这时候发现代码里面有正则还挺花费时间的，不过还好，暂时先不管了。
刚刚都是只运行了一遍，测量结果难免有随机性，必定有失偏颇，实际上应该使用多个测试用例，成千上万次的跑，才能得到一个比较准确地结果。
上面这个小步骤基本没有什么可以优化的了，下面我们把优化目标扩大一点，并把次数先定为100.
下面这种图是按照 tottime 来排序的：
注意其中最耗时的步骤是 parseUnicodeDoc，也就是建树了，这是符合预期的。然而旁边的 ncalls 一栏却不太对劲了。我们明明只运行了 100 次，为什么这个函数调用了 300 次呢？显然代码中有重复建树的地方，也就是有隐藏的 bug。这种地方不经过 profile 很难浮现出来，因为程序本身的逻辑是对的，只是比较耗时而已。
优化之后，终于变成了 100. 从 cProfile 的表格现在已经看不出什么结果来了，下一步我们开始使用火焰图，可视化往往能让我们更容易注视到性能瓶颈。（为什么不一开始就用火焰图呢？因为我以为很麻烦。。实际很简单）
