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.
On 7/19/07, Rik Hemsley <[EMAIL PROTECTED]> wrote:
On 19/07/07, Tony <[EMAIL PROTECTED]> wrote:
>
> Not sure how much interest there is in this, but after being frustrated
> with the performance of Builder I whipped up a mostly Builder-compatible
> frontend to libxml-ruby. My initial benchmarks show it to be about twice as
> fast as builder on large documents:
>
> http://pastie.caboo.se/79575
Nice. I noticed Build was slow, too. Looking forward to seeing it!
Rik
_______________________________________________
libxml-devel mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/libxml-devel
--
Tony Arcieri
ClickCaster, Inc.
[EMAIL PROTECTED]
720-227-0129 ext. 202
_______________________________________________
libxml-devel mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/libxml-devel
