From: Michael Neumann <neumann@...>
Date: 2001-11-12T03:45:14+09:00
Subject: [ruby-talk:24887] Re: ruby and webservices

Sean Russell wrote:
> Markus Jais wrote:
> 
> ....
> >> 1) NQXML
> >> 2) REXML
> >> 3) XMLParser (expat)
> ....
> > I think the XMLParser maybe has the advantage of being faster
> > (and this might often be an issue. I am trying to do some xml programming
> > at work und here performance is the main reason. I'd really like to use
> > ruby or python or at least java, but unfortunately I have to stick to
> > C or C++ as it seems)
> 
> Hi folks,
> 
> Well, I've done some more benchmarks, and with surprising results.  I took 
> the code supplied by TAKAHASHI Masayoshi <maki@inac.co.jp> and added it to 
> REXML's comparison benchmark suite, and here's what I got:
> 
>  function                         REXML        NQXML           XMLParser
>  version                          1.1a         1.1.1            0.6.1
>  Parsing small document          67.6         41.6 (0.62)      107.8 (1.59)
>  Creating and adding new Element 3830.8       5788.0 (1.51)    3729.2 (0.97)
>  Creating a new document tree    758.8        1659.6 (2.19)    560.2 (0.74) 
>  Writing document                 13.0         7.6 (0.58)       N/A 
>  Hand-parsing children            1481.8       2569.4 (1.73)    24.2 (0.02) 
>  XPath                             389.0        N/A              N/A 
>  Parsing large document           4.6          1.6 (0.35)       3.8 (0.83) 
>  Stream parsing                   6.0           2.2 (0.37)       N/A 
> 
> These numbers change as you get faster CPU's; at home I have an AMD 400Mhz. 
> In general, the proportions scale, but sometimes you get a wild number when 
> you move to a different CPU.  In particular, on my Intel 800Mhz machine at 
> work, REXML catches up to and surpasses REXML in the "creating and adding 
> new element" test.  I'm not sure why.
> 
> What does this tell me?  The native XMLParser really isn't faster overall 
> than either REXML or NQXML, and in fact is much slower in some cases.  I 
> therefore retract my earlier statement: if a native implementation doesn't 
> improve the speed, I see no reason to bundle a native implementation with 
> Ruby.  In fact, if speed isn't a factor, I'd vote for a pure Ruby 
> implementation, as it would be easier to maintain.

Did you use the SimpleTreeParser of XMLParser ? It's *very* slow for
really large documents (1 MB, many tags). Very slow means a factor of 
1000+ ! 
But my own benchmarks showed me that the Stream Parser of NQXML is
usually 2 times slower than XMLParser's Stream Parser, which is quite
good for a pure Ruby solution.

Regards,

  Michael

-- 
Michael Neumann
merlin.zwo InfoDesign GmbH
http://www.merlin-zwo.de