Forum: Ruby XML builder performance

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Xin Z. (Guest)
on 2008-10-31 15:02
Hi all,

I have been doing some performance testing, and have noticed it takes
significantly longer to render a XML output then a HTML one. It made me
think perhaps there's a faster way of generating XML than using XML
builder.

I did a quick search and did not find any alternatives, or anyone
talking about XML builder's performance issues.

Is there anyway of optimizing XML Builder? Or is there a faster
alternative?
Dan W. (Guest)
on 2008-10-31 16:15
(Received via mailing list)
The only Ruby Library I've found in the last 2 weeks that seems to do
XMl output is: http://www.tutorialspoint.com/ruby/ruby_xml_xslt.htm

However the builder API is nice and for me personally worth the slightly
longer output. However saying that I managed to output 100 records to
XML within 10 seconds and I don't think it's builder slowing things
down.



Cheers,
Dan
Xin Z. (Guest)
on 2008-10-31 16:23
Dan W. wrote:
> The only Ruby Library I've found in the last 2 weeks that seems to do
> XMl output is: http://www.tutorialspoint.com/ruby/ruby_xml_xslt.htm
>
> However the builder API is nice and for me personally worth the slightly
> longer output. However saying that I managed to output 100 records to
> XML within 10 seconds and I don't think it's builder slowing things
> down.

Thanks for the reply.

I'm using it to output KML on the fly, so every half a second counts. At
the moment, it's taking .5 seconds longer to generate a small-ish file
than it takes for the HTML output.

If there are no clear drop-in alternatives, I might leave off optimising
my KML outputs.

Thanks,
Xin
Avdi G. (Guest)
on 2008-10-31 16:26
(Received via mailing list)
On Fri, Oct 31, 2008 at 9:01 AM, Xin Z. <removed_email_address@domain.invalid> 
wrote:
> I have been doing some performance testing, and have noticed it takes
> significantly longer to render a XML output then a HTML one. It made me
> think perhaps there's a faster way of generating XML than using XML
> builder.

The standard answer for XML performance issues in Ruby is to switch to
libxml-ruby.

--
Avdi

Home: http://avdi.org
Developer Blog: http://avdi.org/devblog/
Twitter: http://twitter.com/avdi
Journal: http://avdi.livejournal.com
Xin Z. (Guest)
on 2008-10-31 16:33
> The standard answer for XML performance issues in Ruby is to switch to
> libxml-ruby.

Isn't libxml-ruby is used for parsing XML? Where as I only need to
output XML.
Avdi G. (Guest)
on 2008-10-31 16:45
(Received via mailing list)
On Fri, Oct 31, 2008 at 10:32 AM, Xin Z. <removed_email_address@domain.invalid>
wrote:
> Isn't libxml-ruby is used for parsing XML? Where as I only need to
> output XML.

You can build and output XML with it.  See for instance the Node
documentation:

http://libxml.rubyforge.org/rdoc/classes/LibXML/XM...

--
Avdi

Home: http://avdi.org
Developer Blog: http://avdi.org/devblog/
Twitter: http://twitter.com/avdi
Journal: http://avdi.livejournal.com
James G. (Guest)
on 2008-10-31 16:53
(Received via mailing list)
On Oct 31, 2008, at 9:32 AM, Xin Z. wrote:

>> The standard answer for XML performance issues in Ruby is to switch
>> to
>> libxml-ruby.
>
> Isn't libxml-ruby is used for parsing XML? Where as I only need to
> output XML.

Have you tried some stupid simple solution like just building the
string manually?

James Edward G. II
Ara H. (Guest)
on 2008-10-31 18:18
(Received via mailing list)
On Oct 31, 2008, at 7:01 AM, Xin Z. wrote:

>
> Is there anyway of optimizing XML Builder? Or is there a faster
> alternative?

try tagz

# gem install tagz

require 'tagz'


xml = Tagz{ foo_{ bar_(:key => :value){ 42 } } }

http://codeforpeople.com/lib/ruby/tagz/tagz-4.4.0/README

a @ http://codeforpeople.com/
Frederick C. (Guest)
on 2008-10-31 18:40
(Received via mailing list)
On 31 Oct 2008, at 13:01, Xin Z. wrote:

>
> Is there anyway of optimizing XML Builder? Or is there a faster
> alternative?

I remember looking at this a while back and it turns out that a
significant bottleneck is how builder escapes your text (look in the
builder source for to_xs). It's doing a lot more that it has too
(although I don't deny that a lot of the time that will be useful).
There's a gem (fast_xs) which implements that in C and makes that
bottleneck a lot faster.

Fred
Mark T. (Guest)
on 2008-10-31 20:40
(Received via mailing list)
I agree with Avdi. LibXML will be the fastest builder-library
solution.

If you want a friendlier interface you can try Nokogiri (http://
nokogiri.rubyforge.org/) which is a wrapper for LibXML.

-- Mark.
Aaron P. (Guest)
on 2008-11-01 19:52
(Received via mailing list)
On Fri, Oct 31, 2008 at 10:01:14PM +0900, Xin Z. wrote:
> Is there anyway of optimizing XML Builder? Or is there a faster
> alternative?

How large are the documents you're trying to build?  If they are small,
I recommend faster-builder:

  http://github.com/codahale/faster-builder/tree/master

Unfortunately its speed diminshes a lot as the number of nodes increase.
If the documents are large, you should try Nokogiri's builder.  I found
it to be faster for larger documents than faster-builder.

Here is my benchmark:  http://gist.github.com/14196

Here is some example builder code:

  http://github.com/tenderlove/nokogiri/wikis/generate
Aaron P. (Guest)
on 2008-11-01 19:52
(Received via mailing list)
On Sat, Nov 01, 2008 at 03:39:01AM +0900, Mark T. wrote:
> I agree with Avdi. LibXML will be the fastest builder-library
> solution.
>
> If you want a friendlier interface you can try Nokogiri (http://
> nokogiri.rubyforge.org/) which is a wrapper for LibXML.

Just so there is no confusion, Nokogiri wraps the libxml2 C library.
Not the LibXML ruby library.  :-)
Stefan K. (Guest)
on 2009-05-04 14:18
I switched a template for a huge xml file from xml builder to erb and
got a threefold speed increase.
This topic is locked and can not be replied to.