XMLライブラリであるNokogiri、Hpricotおよびlibxml-ruby間での軍拡競争で、RubyのXMLストーリーは、近ごろ好転した。昨年秋にリリースされたNokogiriは、ネイティブlibxml2およびlibxsltに基づく(リンク)。
Nokogiriはlibxml2を利用するので、消費者は(とりわけ)高速解析、i13nサポート、高速検索、標準ベースのXPathサポート、名前空間サポートおよびマチュアなHTML補正アルゴリズムを取得する。
またNokogiriは、XPathでの検索やCSSセレクタなどの機能(リンク)を提供し、1.9.1でサポートされる(リンク)。
ベンチマークによりパフォーマンスということになるとNokogiriが首位に立っていることが示された後、Hpricotのメンテナー _whyがライブラリや最近リリースされたバージョンHpricot 0.7(リンク)の改善に向けた努力をおこなった。
興味をそそるような、新しいHpricotで楽しんでください。高速化し、Ruby 1.9のサポートやさまざまな修正があります。
NokogiriおよびLibXMLライブラリによる熾烈な競争をものともせずに、 Hpricotのアップデートの理由は何であるのか疑問を抱いていると思います。Hpricotが依存しておらず、これらのlibsより小型です。 Hpricotは、独自のRagelベースのパーサーを使用するので、パーサー自体に不正侵入することができ、対照によりコードは駆動されます。
とりわけ、Hpricotは過去にJRubyで実行しました。そして、IronRuby code[1]をマージし、0.7をJRubyに移植しているところです。これは、変更することなくコードがさまざまなRubyプラットフォーム上で実行することを意味します。それだけでも価値があると思いませんか?
以下の機能を備え、libxml-rubyがバージョン1.0(リンク)としてついにリリースされた。
* Ruby 1.9.1のサポート
* すぐに使えるOS X 10.5およびMacPortsのサポート
* 単純なことを簡単に実行するすばらしく、明快なAPIであるが、必要時にはlibxml2のあらゆる機能を提供する
最新のバージョンは1.1.3であり、重要な改善を伴ってリリースされた(リンク)。
1つずつオプションを片付けていき、ついに問題の原因を突き止めた。構造内の曖昧なフィールドである。int dictNames : Use dictionary names for the treeこの設定が制御するのは、libxml2がディクショナリーを使用して、以前に解析された文字列をキャッシュするかどうかである。文字列のキャッシュは、 大きな違いが生じるので、デフォルトでは有効にしておく。それは、libxml-ruby 1.2.3以降の場合である。
この変更により、libxml-rubyはNokogiriとほぼ同程度のパフォーマンスで実行する。