Ruby XML Roundup: Hpricot 0.7, Libxml-ruby estável e Nokogiri

A história do XML no Ruby melhorou recentemente com uma pequena corrida entre exércitos entre as bibliotecas para XML Nokogiri, Hpricot e libxml-ruby. Nokogiri foi lançado no outono passado e baseia-se nas bibliotecas nativas libxml2 e libxslt:

Uma vez que o Nokogiri se apoia na libxml2, consumidores ganham (entre outras coisas) parsing rápido, suporte a i13n, buscas rápidas, suporte a XPath baseado em padrões, suporte a namespaces e algorítmos para correção de HTML maduros.

O Nokogiri também possui funcionalidades de pesquisa através de Xpath e seletores CSS e pode ser utilizado com o Ruby 1.9.1.

Após alguns benchmarks terem mostrado que o Nokogiri está na frente quando o assunto é desempenho, o mantenedor do Hpricot _why esforçou-se para melhorar a biblioteca e recentemente lançou a versão 0.7 do Hpricot:

Por favor divirtam-se com um novo e suculento Hpricot. Um pouco mais rápido, com algum suporte a Ruby 1.9 e com alguns consertos [..]

Tenho certeza que você deve estar pensando qual é razão para as atualizações do Hpricot, tendo em vista a quente competição entre as bibliotecas Nokogiri e LibXML. Lembre-se de que o Hpricot não possui dependências e é menor que qualquer uma dessas bibliotecas. O Hpricot utiliza um parser Ragel próprio, logo você tem a liberdade de alterar o parser, o código é muito menor se comparado.

Ainda melhor, o Hpricot já rodou sobre Jruby no passado. E eu estou introduzindo alguns códigos[1] do IronRuby e portando a versão 0.7 para Jruby. Isso significa que o seu código poderá ser executado em diversas plataformas Ruby sem alterações. Só isso já faz com que valha à pena, você não concorda?

Finalmente, o libxml-ruby foi lançado como a versão 1.0 com:

* Suporte ao Ruby 1.9.1
* Suporte para OS X 10.5 e MacPorts [..]
* Uma API agradável e limpa que torna fácil fazer coisas simples, mas provê todo o poder da libxml2 caso você precise

A versão mais atual é a 1.1.3, a qual foi lançada com uma melhoria crucial:

Trabalhando sobre as opções uma a uma, eu finalmente encontrei o culpado, um campo obscuro na estrututa:

int     dictNames       : Use dictionary names for the tree

O que esse código faz é controlar se o libxml2 deve ou não utilizar um dicionário para armazenar strings já analisadas anteriormente. Armazenar strings faz uma grande diferença, logo por padrão isso deve estar habilitado. Isso é o que acontece com o libxml-ruby 1.2.3 e com as versões superiores.

Com essa alteração, o libxml-ruby possui agora desempenho praticamente igual ao do Nokogiri.