lxml 简介
Python 从来不出现 XML 库短缺的情况。从 2.0 版本开始，它就附带了 xml.dom.minidom 和相关的 pulldom 以及 Simple API for XML (SAX) 模块。从 2.4 开始，它附带了流行的 ElementTree API。此外，很多第三方库可以提供更高级别的或更具有 python 风格的接口。
尽管任何 XML 库都足够处理简单的 Document Object Model (DOM) 或小型文件的 SAX 解析，但开发人员越来越多碰到更加大型的数据集，以及在 Web 服务上下文中实时解析 XML 的需求。同时，经验丰富的 XML 开发人员可能倾向于使用原本就支持 XML 的语言，例如 XPath 或 XSLT，这样可以保持紧凑和表达力。最理想的情况是使用 XPath 的声明式语法，同时保留 Python 的通用的功能。
本文使用的软件版本和示例数据
- lxml 2.1.2
- libxml2 2.7.1
- libxslt 1.1.24
- cElementTree 1.0.5
- United States 版权更新（copyright renewal）数据，由 Google 提供
- Open Directory Resource Description Framework (RDF) 内容
有关软件和数据的更多信息，请参阅 参考资料。
我执行的基准测试使用了 Pentium M 1.86GHz ThinkPad T43、2GB RAM，运行 Ubuntu，使用 IPython 的 timeit 命令。计时的目的主要是为了比较方法，因此不应该作为所述软件的代表性基准。
lxml 是第一款表现出高性能特征的 Python XML 库，它天生支持 XPath 1.0、XSLT 1.0、定制元素类，甚至 python 风格的数据绑定接口。它构建在两个 C 库之上：libxml2 和 libxslt。它们为执行解析、序列化和转换等核心任务提供了主要动力。
您要在代码中使用 lxml 的哪一部分取决于您的需求：您是否熟悉 XPath？是否希望使用类似 Python 的对象？系统中有多少内存可用来维持大型树？
本文并没有介绍 lxml 的所有部分，但是演示了一些可以有效处理大型 XML 文件、进行优化以提高处理速度并减少内存使用的技术。这里使用了两种可免费使用的示例文档：Google 将其转换为 XML 的 U.S. 版权更新数据和 Open Directory RDF 内容。
这里只将 lxml 与 cElementTree 比较，而没有与其他 Python 库进行比较。选择 cElementTree 是因为它和 lxml 一样是 Python 2.5 的一部分，并且构建在 C 库之上。
超大型的数据会引起什么问题？
XML 库通常针对非常小的示例文件进行设计和测试。事实上，很多实际项目最初并没有完整的可用数据。编程人员一连数周或数月都使用示例内容，并编写如 清单 1 所示的代码。
cElementTree
如果程序的任务就是解析和执行简单的分析，可以考虑使用 cElementTree 模块，它是 Python 2.5 的一部分。它是 ElementTree 的 C 实现，使用 expat 进行解析，并且在解析完整的文档树方面比其他库强大。然而，它的 API 限制比 ElementTree 还多，并且在执行大多数其他任务时（特别是执行序列化时）速度比 lxml 慢。
清单 1. 一个简单的解析操作
|
1 2 |
|
lxml parse 方法读取整个文档并在内存中构建一个树。相对于 cElementTree，lxml 树的开销要高一些，因为它保持了更多有关节点上下文的信息，包括对其父节点的引用。使用这种方法解析一个 2G 的文档时，会使一个具有 2G RAM 的机器进入交换，这会大大影响性能。假设在编写应用程序时这些数据在内存中可用，那么将要执行较大的重构。
迭代解析
如果构建内存树并不是必须的或并不实际，则可以使用一种迭代解析技术，这种技术不需要读取整个源树。lxml 提供了两种方法：
- 提供一个目标解析器类
- 使用
iterparse方法
使用目标解析器方法
目标解析器方法对于熟悉 SAX 事件驱动代码的开发人员来说应该不陌生。目标解析器是可以实现以下方法的类：
start在元素打开时触发。数据和元素的子元素仍不可用。end在元素关闭时触发。所有元素的子节点，包括文本节点，现在都是可用的。data触发文本子节点并访问该文本。close在解析完成后触发。
清单 2 演示了如何创建实现所需方法的目标解析器类（这里称为 TitleTarget）。这个解析器在一个内部列表（self.text）中收集 Title 元素的文本节点，并在到达 close() 方法后返回列表。
清单 2. 一个目标解析器，它返回 Title 标记的所有文本子节点的列表
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
|
在运行版权数据时，代码运行时间为 54 秒。目标解析可以实现合理的速度并且不会生成消耗内存的解析树，但是在数据中为所有元素触发事件。对于特别大型的文档，如果只对其中一些元素感兴趣，那么这种方法并不理想，就像在这个例子中一样。能否将处理限制到选择的标记并获得较好的性能呢？
使用 iterparse 方法
lxml 的 iterparse 方法是 ElementTree API 的扩展。iterparse 为所选的元素上下文返回一个 Python 迭代器。它接受两个有用的参数：要监视的事件元组和标记名。在本例中，我只对 <Title> 的文本内容感兴趣（达到 end 事件即可获得）。清单 3的输出与 清单 2 的目标解析器方法的输出相同，但是速度应该会提高很多，因为 lxml 可以在内部优化事件处理。同时也会减少代码量。
清单 3. 对指定的标记和事件进行简单迭代
|
1 2 3 4 |
|
如果运行这段代码并监视它的输出，可以看到它首先会非常快速地追加标题，然后又马上减缓下来。快速检查 top 会发现计算机已经进入交换：
|
1 2 |
|
这里发生了什么？尽管 iterparse 起初并没有消耗整个文件，但它也没有释放对每一次迭代的节点的引用。当对整个文档进行重复访问时，这点必须注意。不过，在本例中，我选择在每次循环结束后回收内存。这包括对已经处理的子节点和文本节点的引用，以及对当前节点前面的兄弟节点的引用。这些引用中来自根节点的引用也被隐式地保留，如 清单 4 所示：
清单 4. 修改后的迭代去掉了不需要的节点引用
|
1 2 3 4 5 6 7 8 9 |
|
为简单起见，我将 清单 4 重构为一个函数，它接受一个可调用的 func 对当前节点执行操作，如 清单 5 所示。我将在后面的示例中使用这个方法。
清单 5. 函数循环遍历上下文并在每次循环时调用 func，然后清除不必要的引用
|
1 2 3 4 5 6 7 |
|
性能特点
清单 4 中的 iterparse 方法经过优化后生成的输出与 清单 2 中目标解析器生成的输出相同，但只用了一半的时间。当处理特定事件或标记名（比如本例）时，处理速度甚至比 cElementTree 还快。（但是，大多数情况下，如果解析是主要活动的话，cElementTree 的表现要比 lxml 优秀）。
表 1 展示了各种解析器技术在 基准测试侧边栏 中描述的计算机上测试版权数据使用的时间。
表 1. 比较迭代解析方法：从 <Title> 提取 text()
| XML 库 | 方法 | 平均时间，单位（秒） |
|---|---|---|
| cElementTree | Iterparse | 32 |
| lxml | 目标解析器 | 54 |
| lxml | 优化后的 iterparse | 25 |
它的伸缩性如何？
对 Open Directory 数据使用 清单 4 中的 iterparse 方法，每次运行耗时 122 秒，约是解析版权数据所用时间的 5 倍。由于 Open Directory 数据的数量也约是版权数据的 5 倍（1.9 GB），这种方法应该表现出非常好性能，对特别大的文件尤其如此。
序列化
如果对 XML 文件所做的全部操作只是从单个节点获取一些文本，可以使用一个简单的正则表达式，其处理速度可能会比任何 XML 解析器都快。但是在实践中，如果数据非常复杂，则几乎不可能完成任务，因此不推荐使用这种方法。在需要真正的数据操作时，XML 库的价值是不可估量的。
将 XML 序列化为一个字符串或文件是 lxml 的长项，因为它依赖于 libxml2 C 代码库。如果要执行要求序列化的任务，lxml 无疑是最佳选择，但是需要使用一些技巧来获得最佳性能。
在序列化子树时使用 deepcopy
lxml 保持子节点及其父节点之间的引用。该特性的一个特点就是 lxml 中的节点有且仅有一个父节点（cElementTree 没有父节点）。
清单 6 包含版权文件中的所有 <Record>，并写入了一条只包含标题和版权信息的简化记录。
清单 6. 序列化元素的子节点
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
|
不要使用 deepcopy 复制单个节点的文本。手动创建新节点、填充文本属性并进行序列化，这样做的速度更快。在我的测试中，对 <Title> 和 <Copyright> 调用 deepcopy 要比 清单 6 中的代码慢 15%。在序列化大型后代树（descendant trees）时，会看到 deepcopy 将使性能得到巨大的提升。
在使用 清单 7 中的代码对 cElementTree 进行基准测试时，lxml 的序列化程序的速度几乎提高了两倍（50% 和 95%）：
清单 7. 使用 cElementTree 序列化
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
|
有关迭代模式的更多信息，请参阅 ElementTree 文档 “Incremental Parsing”（参见 参考资料 获得链接）。
快速查找元素
完成解析后，最常见的 XML 任务是在解析后的树中查找特定的数据。lxml 提供了简化的搜索语法和完整的 XPath 1.0 等各种方法。作为用户，您应当了解每种方法的性能特征和优化技巧。
避免使用 find 和 findall
find 和 findall 方法继承自 ElementTree API，可使用简化的类似 XPath 的表达式语言（称为 ElementPath）查找一个或多个后代节点。从 ElementTree 迁移过来的用户可以继续使用 find/ElementPath 语法。
lxml 提供了另外两种查找子节点的选项：iterchildren/iterdescendants 方法和真正的 XPath。如果表达式需要匹配一个节点名，那么使用 iterchildren 或 iterdescendants 方法以及其可选的标记参数，这要比使用 ElementPath 表达式快很多（有时速度会快上两倍）。
对于更复杂的模式，可以使用 XPath 类预编译搜索模式。使用标记参数（例如 etree.XPath("child::Title")）模拟 iterchildren 行为的简单模式的执行时间与 iterchildren 是相同的。但是，预编译仍然非常重要。在每次执行循环时编译模式或对元素使用 xpath() 方法（参见 参考资料 中 lxml 文档的描述），几乎比与只编译一次然后反复使用模式慢 2 倍。
lxml 中的 XPath 计算非常快。如果只需要对一部分节点进行序列化，那么在检查所有节点之前使用精确的 XPath 表达式限制条件，这样效果会好很多。例如，限制示例序列化使其只包括含有 night 单词的标题，如 清单 8 所示，这只需序列化完整数据所用的时间的 60%。
清单 8. 使用 XPath 类进行有条件的序列化
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
|
在文档的其他部分查找节点
注意，即使使用了 iterparse，仍然可以根据当前的节点 使用 XPath 谓词。要查找后面紧跟一个记录（记录的标题包含单词 night）的所有 <Record> 节点，则执行以下操作：
|
1 |
|
然而，如果使用 清单 4 描述的节省内存的迭代策略，该命令将不会返回任何内容，因为解析完整个文档时将删除前面的节点：
|
1 |
|
虽然可以编写有效的算法来解决这一问题，但是对于那些需要跨节点进行分析的任务（特别是那些随机分布在文档中的节点），使用使用 XQuery（比如 eXist）的 XML 数据库更加适合。
提高性能的其他方法
除了使用 lxml 内部 的特定方法外，还可以通过库以外的方法提高执行速度。其中一些方法只需要修改一下代码；而另一些方法则需要重新考虑如何处理大型数据。
Psyco
Psyco 模块常常被忽略，但是它可以通过较少的工作提高 Python 应用程序的速度。一个纯 Python 程序的典型性能收益是普通程序的 2 至 4 倍，但是 lxml 使用 C 语言完成了大部分工作，因此它们之间的差别非常小。当我在启用 Psyco 的情况下运行 清单 4 时，运行时间仅仅减少了 3 秒（43.9 秒对 47.3 秒）。Psyco 需要很大的内存开销，如果机器进入交换，它甚至会抵销 Python 获得的任何性能。
如果由 lxml 驱动的应用程序包含频繁执行的核心纯 Python 代码（可能是对文本节点执行的大量字符串操作），那么仅对这些方法启用 Psyco 可能会有好处。有关 Psyco 的更多信息，参见 参考资料。
线程化
相反，如果应用程序主要依赖内部的、C 驱动的 lxml 特性，那么可能适合将它作为多处理环境下的线程化应用程序运行。关于如何启动线程有很多限制 — 对 XSLT 而言尤其如此。要了解更多内容，可参考 lxml 文档中有关线程的 FAQ 部分。
拆分解决
如果可以将特别大的文档分解为单个的、可分析的子树，那么就可以在子树级别上分解文档（使用 lxml 的快速序列化），并将工作分布到位于多台计算机中的这些文件。对于执行 CPU 密集型的脱机任务，使用随需应变的虚拟服务器正成为一种日益流行的解决方案。可以获得 Python 程序员用于设置和管理 Amazon 虚拟 Elastic Compute Cloud (EC2) 集群的详细指南。参见 参考资料 了解更多信息。
适合大型 XML 任务的一般策略
本文给出的具体代码示例可能并不适合您的项目，但是对于 GB 级或以上的 XML 数据，请考虑以下的原则（已通过测试和 lxml 文档的验证）：
- 使用迭代解析策略，渐进式地处理大型文档。
- 如果需要随机地搜索整个文档，那么使用索引式 XML 数据库。
- 只选择需要的数据。如果只对特定的节点感兴趣，使用按名字选择的方法。如果需要谓词语法，那么尝试可用的 XPath 类和方法。
- 考虑手头的任务和开发人员的舒适程度。如果不需要考虑速度的话，lxml 的对象化或 Amara 等对象模型对于 Python 开发人员来说可能更自然。cElementTree 在只需要进行解析时才会体现出速度优势。
- 花些时间做些非常简单的基准测试。在处理数百万条记录时，细微的差别就会累积起来，但是并不能总是很明显地看出哪种方法最有效。
结束语
很多软件产品都附带了 pick-two 警告，表示在速度、灵活性或可读性之间只能选择其中两种。然而，如果得到合理使用，lxml 可以满足全部三个要求。那些希望提高 DOM 性能或使用 SAX 事件驱动模型的 XML 开发人员现在有机会获得更高级的 Python 库。拥有 Python 背景的开发人员在刚开始接触 XML 时也可以轻松地利用 XPath 和 XSLT 的表达能力。这两种编程风格可以在一个基于 lxml 的应用程序中和谐共存。
本文只介绍了 lxml 的一小部分功能。请查看 lxml.objectify 模块，它主要针对那些较小的数据集或对 XML 的依赖不是强的应用程序。对于不具备良好格式的 HTML 内容，lxml 提供了两个有用的包：lxml.html 模块和 BeautifulSoup 解析器。如果要编写能够从 XSLT 调用的 Python 模块，或创建定制的 Python 或 C 扩展，还可以扩展 lxml。可以从 参考资料 中的 lxml 文档中找到有关所有这些内容的信息。