On 7/19/07, Tony Arcieri <[EMAIL PROTECTED]> wrote:
> Well, I was excited about this idea, but started getting diminishing
> returns, at least in the test cases I was using:
>
> The basic pattern is:
>
> xml = Builder::XmlMarkup.new ; xml.foo(:a => :b) { N.times { xml.bar (:c =>
> :d) { 1000.times { xml.baz("Text goes here") } } } }
>
> with N increasing. This also includes a .to_s on the libxml Builder version
> which outputs the actual markup.
>
> 200 children w\ 1000 grandchildren each:
>
> Builder: 18.560000 0.030000 18.590000 ( 18.593951)
> libxml: 9.030000 5.410000 14.440000 ( 14.485134)
>
> Where libxml Builder was twice as fast on the original benchmarks I posted,
> here it's only marginally faster.
>
> 300 children w\ 1000 grandchildren each:
>
> Builder: 27.860000 0.040000 27.900000 ( 27.905695)
> libxml: 17.760000 12.160000 29.920000 ( 29.931187)
>
> Here Builder has surpassed libxml Builder.
>
> 400 children w\ 1000 grandchildren each:
>
> 37.150000 0.050000 37.200000 ( 37.204134)
> 28.380000 21.610000 49.990000 ( 50.522918)
>
> I didn't go beyond that.
>
> Anyway, any ideas what the slowdown might be? Seems like the native
> extension bit isn't scaling linearly with the document size.
I'm not sure, but I created a template system that could used either
libxml or rexml on the back-end. Disturbingly rexml was faster!
Something is very wrong.
T.
_______________________________________________
libxml-devel mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/libxml-devel
