使用由 Python 编写的 lxml 实现高性能 XML 解析

转载自：文章

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 的通用的功能。

我执行的基准测试使用了 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 所示的代码。
清单 1. 一个简单的解析操作

from lxml import etree
doc = etree.parse('content-sample.xml')

lxml parse 方法读取整个文档并在内存中构建一个树。相对于 cElementTree，lxml 树的开销要高一些，因为它保持了更多有关节点上下文的信息，包括对其父节点的引用。使用这种方法解析一个 2G 的文档时，会使一个具有 2G RAM 的机器进入交换，这会大大影响性能。假设在编写应用程序时这些数据在内存中可用，那么将要执行较大的重构。

迭代解析
如果构建内存树并不是必须的或并不实际，则可以使用一种迭代解析技术，这种技术不需要读取整个源树。lxml 提供了两种方法：

• 提供一个目标解析器类
• 使用 iterparse 方法

使用目标解析器方法

目标解析器方法对于熟悉 SAX 事件驱动代码的开发人员来说应该不陌生。目标解析器是可以实现以下方法的类：

start 在元素打开时触发。数据和元素的子元素仍不可用。
end 在元素关闭时触发。
所有元素的子节点，包括文本节点，现在都是可用的。
close 在解析完成后触发。

清单 2 演示了如何创建实现所需方法的目标解析器类（这里称为 TitleTarget）。这个解析器在一个内部列表（self.text）中收集 Title 元素的文本节点，并在到达 close() 方法后返回列表。

清单 2. 一个目标解析器，它返回 Title 标记的所有文本子节点的列表

class TitleTarget(object):
    def __init__(self):
        self.text = []
    def start(self, tag, attrib):
        self.is_title = True if tag == 'Title' else False
    def end(self, tag):
        pass
    def data(self, data):
        if self.is_title:
            self.text.append(data.encode('utf-8'))
    def close(self):
        return self.text

parser = etree.XMLParser(target = TitleTarget())

# This and most other samples read in the Google copyright data
infile = 'copyright.xml'

results = etree.parse(infile, parser)    

# When iterated over, 'results' will contain the output from 
# target parser's close() method

out = open('titles.txt', 'w')
out.write('\n'.join(results))
out.close()

在运行版权数据时，代码运行时间为 54 秒。目标解析可以实现合理的速度并且不会生成消耗内存的解析树，但是在数据中为所有元素触发事件。对于特别大型的文档，如果只对其中一些元素感兴趣，那么这种方法并不理想，就像在这个例子中一样。能否将处理限制到选择的标记并获得较好的性能呢？

使用 iterparse 方法

lxml 的 iterparse 方法是 ElementTree API 的扩展。iterparse 为所选的元素上下文返回一个 Python 迭代器。它接受两个有用的参数：要监视的事件元组和标记名。在本例中，我只对 的文本内容感兴趣（达到 end 事件即可获得）。清单 3 的输出与 清单 2 的目标解析器方法的输出相同，但是速度应该会提高很多，因为 lxml 可以在内部优化事件处理。同时也会减少代码量。
清单 3. 对指定的标记和事件进行简单迭代

context = etree.iterparse(infile, events=('end,'), tag='Title')

for event, elem in context:
       out.write('%s\n' % elem.text.encode('utf-8'))

    如果运行这段代码并监视它的输出，可以看到它首先会非常快速地追加标题，然后又马上减缓下来。快速检查 top 会发现计算机已经进入交换：
    PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                
    170 root      15  -5     0    0    0 D  3.9  0.0   0:01.32 kswapd0

这里发生了什么？尽管 iterparse 起初并没有消耗整个文件，但它也没有释放对每一次迭代的节点的引用。当对整个文档进行重复访问时，这点必须注意。不过，在本例中，我选择在每次循环结束后回收内存。这包括对已经处理的子节点和文本节点的引用，以及对当前节点前面的兄弟节点的引用。这些引用中来自根节点的引用也被隐式地保留，如 清单 4 所示：

清单 4. 修改后的迭代去掉了不需要的节点引用：

for event, elem in context:
    out.write('%s\n' % elem.text.encode('utf-8'))        

    # It's safe to call clear() here because no descendants will be accessed
    elem.clear()

    # Also eliminate now-empty references from the root node to 
    #   dateid
    # 

    # Create a new root node
    r = etree.Element('SimplerRecord')

    # Create a new child
    t = etree.SubElement(r, 'Title')

    # Set this child's text attribute to the original text contents of