最近由于Nokogiri、Hpricot及libxml-ruby之间的竞争致使 Ruby 的XML支持得到了极大的改进。Nokogiri 发布于去年秋天,它基于本地的 libxml2 和 libxslt :
由于 Nokogiri 使用了 libxml2,因此使用者可以获得如下好处:快速解析、i18n 支持、快速搜索、基于标准的 XPath 支持、命名空间支持及成熟的 HTML 修正算法。
Nokogiri 还具有诸如使用 XPath 和 CSS 选择符进行搜索的特性,同时它还支持 Ruby 1.9.1 。
一些基准的结果表明 Nokogiri 的性能是最棒的,之后 Hpricot 的维护者就花费了大量心力对该库进行改进并发布了 Hpricot 0.7 :
来享受这个新的、卓越的 Hpricot 吧。它快一些、支持 Ruby 1.9 而且还进行了不少修复… 我敢肯定你想知道为何面对 Nokogiri 和 LibXML 的强大竞争我还要更新 Hpricot 呢。记住 Hpricot 不依赖于其他任何东西,同时它比这两个库都要小。Hpricot 使用的是自己的基于 Ragel 的解析器,这样你就可以随意修改解析器了,相对来说其代码也更精简。
最重要的是过去 Hpricot 曾运行在 JRuby 上。现在我正忙于将 IronRuby 和 0.7 版的一些代码合并到 JRuby 上。这意味着无需调整你的代码就能运行在多种 Ruby 平台上,因此我这么做值了,你觉得呢?
最后 libxml-ruby 也发布了 1.0 版:
* 支持 Ruby 1.9.1
* 对 OS X 10.5 和 MacPorts 开箱即用的支持
* 优雅、干净的 API 可以轻松完成一些简单的事情,同时还提供了你所需要的 libxml2 的所有功能
通过一个个的检查,最后我终于发现了一个隐蔽的问题: ```
int dictNames : Use dictionary names for the tree
复制代码
该设置控制的是 libxml2 是否使用 dictionary 来缓存之前解析过的字符串。字符串的缓存与否会对性能造成极大的影响,因此默认情况下缓存应该是开启的。目前 libxml-ruby 1.2.3+ 采取的都是这种方式。
借助于这个改变,现在 libxml-ruby 的性能与 Nokogiri 已不相上下。
查看英文原文: Ruby XML Roundup: Hpricot 0.7, Stable Libxml-ruby and Nokogiri
评论