在前两篇博客 Scrapy进行大规模抓取(1) 和 Scrapy进行大规模抓取(2) 讲解Scrapy抓取时，就应该对现有的一些解析器和文档模型做个性能对比。

实际上，情况有点复杂，因为处理HTML需要几个步骤：

  1. 解析这个 HTML
  2. 把它解析为一个对象（比如一个Document Tree文档对象）
  3. 把它序列化

有些解析器只处理第一步，有些只处理第二步，有些能处理所有的三个步骤…。

例如，ElementSoup 使用ElementTree 来表示文档，却使用 BeautifulSoup 作为实际的解析器，而 BeautifulSoup 内部也拥有一个文档对象。 HTMLParser 仅仅做解析（不解析出任何对象），然而 html5lib 却能够生成几种不同的文档树（DOM树）。序列化也分为XML和HTML两种方式。

所以我选取了下面这些解析器的库做基准性能测试：

  • lxml：包含一个解析器，能够产生文档对象，支持HTML序列化。它也可以不适用内置的解析器而使用 BeautifulSoup 或者 html5lib 进行解析。
  • BeautifulSoup：包含一个解析器，能够产生文档对象，支持HTML序列化。
  • html5lib：有解析器，它也有一个序列化器，但是我没有使用它。它也有一个内置的文档对象（即simpletree），只是…除了自我测试我也不知道这东西还能做什么。
  • ElementTree：这个包里有一个XML序列化器，ElementTree能够产生文档对象，它也是python内置的XML解析模块。（我觉得下个版本会带一个HTML序列化器，不过我也没测试这个XML序列化器）。它也有一个解析器，测试的时候我用html5lib当做解析器来测试ElementTree的。
  • cElementTree：这是一个使用C语言扩展实现的python模块，实现了ElementTree。
  • HTMLParser：包含一个解析器，但是其实它不能解析出文档对象，很多正常网页都不能正常处理（包含Table或者Script），有语法错误的网页就更处理不了了。它只是使用解析器遍历文档。
  • htmlfill：它使用了HTMLParser作为解析器，相对HTMLParser，它在解析过程中对Element做了更多处理。
  • Genshi：包含一个解析器，能够产生文档对象，支持HTML序列化。
  • xml.dom.minidom：Python标准库里的内置文档模型，html5lib 能够解析出这种文档对象。（我并不推荐使用minidom — 这篇文章里写了一些理由，还有很多理由我没写出来）

我预想 lxml 的性能会比较好，因为它基于 libxml2这个C库。但是实际上它的性能比我预计的还要好，超过其它所有的同类库。所以，除非考虑到一些难以解决的安装问题（尤其是在Mac上），我都推荐你用lxml 来进行HTML解析的工作。

 

我的测试代码在这里，你可以自己下载下来运行测试程序。里面包含了所有的样例数据，用来生成图表的命令在这里。这些测试数据来自于从 python.org 随机选取的一些页面（总共355个）。

解析

python-html-parser-performance-evaluation-01

第一个测试运行这些解析器解析文档。需要注意的是：lxml 比 HTMLParser快6倍，尽管 HTMLParser不生成任何文档对象（lxml在内存中建立了一个文档树)。这里也没有包含 html5lib 所能生成的全部种类的树，因为每一种花费的时间都差不多。之所以包含了使用 xml.dom.minidom 作为输出结果的 html5lib 测试结果是为了说明 minidom 有多慢。Genshi确实很快，只是它也是最不稳定的，相比之下，html5lib , lxml 以及 BeautifulSoup 都要健壮的多。html5lib 的好处是，总是能够正确的解析HTML（至少在理论上如此）。

lxml在解析过程中会释放 GIL ，但是我觉得应该影响不大。

 

序列化

python-html-parser-performance-evaluation-02

所有这些库执行序列化都很快，可是 lxml 又一次遥遥领先。ElementTree 和 minidom 只做XML序列化，但是没有理由说HTML序列化更快。还有就是，Genshi居然比minidom要慢，实话说任何比minidom要慢的东西都挺让人震惊的。

 

内存占用

python-html-parser-performance-evaluation-03

最后一项测试是内存。我并不是特别确信我做这个测试的方法很科学，但是数据总能说明一些问题。这项测试会解析所有的文档并把解析出来的DOM树保存在内存中，利用 ps 命令结果的RSS（resident set size）段来表示进程占用的内存。计算基准内存占用之后所有的库已经被import，所以只有解析HTML和生成文档对象会导致内存使用量上升。

我才用 HTMLParser 作为基准线，因为它把文档保存在内存中，只产生一些中间字符串。这些中间字符串最终也不回占用多少内存，因为内存占用基本上等同于这些html问价大小之和。

测量过程中有个棘手的问题就是python的内存分配器并不会释放它请求的内存，所以，如果一个解析器创建了很多中间对象（字符串等等）然后又释放了它们，进程仍然会持有这些内存。为了检测是否有这种情况，我试着分配一些新的字符串知道进程占用的内存增长（检测已经分配但是没有被使用的内存），但是实际上没检测到什么，只有 BeautifulSoup 解析器，在序列化到一个 lxml 树的时候，显示出使用了额外的内存。

只有在内存测试中，html5lib 使用 cElementTree 来表示文档对象同使用 ElementTree 能表现出明显的不同。我倒不是很惊讶，我猜因为我没有找到一个C语言编写的序列化工具，我猜使用 cElementTree 构建文档树的话，只有在用本地代码调用它的时候比较快（就像本地的libxml，并且不需要把数据结构传递到python中）。

lxml比较节省内存很可能是因为它使用了本地的libxml2的数据结构，并且只有在需要的时候才创建Python对象。

 

总结

在进行基准测试之前我就知道lxml会比较快，但是我自己也没料到会这么快。

所以呢，总结一下：lxml太牛逼了。你可以用很多种方式使用它，你可以对一个HTML进行解析，序列化，解析，再序列化，在机器卡机之前你能重复这些操作很多次。很多操作都是通过本地接口实现的，python只做了一层很浅的封装。例如，如果你做一次XPath查询，查询字符串会被编译为本地代码，然后遍历本地的libxml2对象，只在返回查询结果的时候才会产生一个python对象。 另外，测试中lxml内存占用比较小使我更有理由相信lxml在高负载的情况下仍然会很可靠。

我觉得，文档树相对按字符流解析（不生成树，只扫描一次文档并针对特定的标签做处理）更有优势。表面看起来按字符流解析更好：你不把整个文档放在内存里，处理的时间之和文档大小线性相关。HTMLParser就是这样一种解析器，遇到各种符号（标签开始和关闭，变迁中间的文字等等）。

Genshi 也是用的这个模型，因为使用了一些更高级的特性（比如 filters）所以使用起来更自然一些。其实字符流模型本身就不是一种特别自然的处理XML文档的方式，从某种程度上说，它只是用来处理一些本来就可以当做字符串处理的文档的一种笨拙的方法（regex可以实现同样的功能）。只有你需要处理上G的XML文件的时候按字符流解析才有意义（不过lxml和ElementTree针对这种情况都有额外的参数支持）。HTML文件不会有这么大，这些测试也有理由让我们相信lxml可以很好的处理大的HTML文件，所以一个大文档也不会导致一个为小文档优化过的系统崩溃。

Ian Bicking on Sunday, March30th, 2008

[1]. Genshi是EdgewallSoftware的产品，它的其他产品还包括大名鼎鼎的Trac。

[2]. 本文的作者Ian Bicking是lxml.html(lxml的一个模块)的开发者和维护者（这里修正一下）。

P.S. 译者记：这里还有一个解析器没有提到就是python标准库里的SGMLParser，它也可以产生ElementTree，但是性能很差，本机测试解析600k的html文档（ddd的单页html文档）需要480秒，不推荐应用在性能要求比较高的场合。本文作者也是lxml的作者，对自己的作品大力推荐也是正常的，我实测过lxml性能确实很好。