views:

6796

answers:

8

Hi everyone,

I'm curious what your solution is for high performance XML parsing on the iPhone is, given its limited amount of CPU power. I have reviewed the XML Performance App that Apple provides as a demonstration, and it seems that for the data feed (300 iTunes songs) that they're parsing.. libxml2 always seem to come as the forefront winner.

With your experience in dealing with data that's < 100Kb, what do you prefer for optimal performance? I'm currently using TouchXML + libxml2 and looking to see if it's possible to optimize on the parsing speeds as is.

Thanks for your feedback!

+9  A: 

I've generally found for larger chunks of data (like the apple example you reference) libxml2 tends to be faster. For smaller chunks of data, the difference is negligible. One advantage i like about NSXMLParser is that it is an Objective-C based implementation of an XML Parser where libxml2 is C based.

zPesk
+13  A: 
Jim Dovey
+5  A: 

I tried my data (about 600 records) using the XML parsing app apple provides. Found the libxml2 to be much faster than NSXMLParser. I switched to libxml2 (though I find it a bit more complex to implement than NSXMLParser, it suited my purpose well)

The same example tried with about a 100 records does not have much difference in both the implementations.

lostInTransit
A: 

libxml2 is faster than the NSXMLParser, as well as more flexible. It also has a very small (but noticable) memory leak with the xmlReader interface (my favorite interface of the set) in the SDK released with iPhone OS 2.2.1. Details embedded in http://inessential.com/2009/02/25/moving_to_libxml2_sax2. Other interfaces within libxml2 don't have that issue - just so happens my favorite one does.

Functionally, you won't notice the difference with relatively small amounts of XML, but if you find yourself wading through a large set streamed into the parser, it will get noticeable.

As zPesk mentioned, for smaller amounts of data you may find the benefit of working straight with Objective-C more beneficial than the small amount of performance you get.

heckj
A: 

I've used Objective-Xml. This is another drop in replacement for NSXMLParser. It gave me about a 15 second improvement on a file that was taking over 1 minute to parse. Still too slow though.

Ian1971
A: 

libxml2 is always going to be faster than NSXMLParser. NSXMLParser gives you a decent event-bsaed API, but it's built on top of libxml2 and it also isn't stream-based (e.g. NSXMLParser hands the entire block of data to libxml2 at once).

If you're optimizing for speed, libxml2 is definitely the way to go. However if you want an obj-c event-based API and don't care so much about performance, NSXMLParser is the right tool for the job. And please note that NSXMLParser isn't necessarily slow, it's just not as fast as libxml2.

Kevin Ballard
+5  A: 

libxml2 will always be faster than NSXMLParser for many reasons, however, it is up to you which is more useful to your project.

NSXMLParser, overall, is prettier. The code makes sense, as sax parser's are won't to be, and it is a real Cocoa class with all the conventions there. If convenience and clean code are your top priorities, then you should stick with NSXMLParser.

While NSXMLParser uses libxml2 on the backend, it is slower due to the foundations of Objective-C and the achilles heel of ObjC. When parsing XML, you're essentially just doing a bunch of tight loops over and over again while searching for the tags you're interested in.

Herein lies the lesson - when in a tight loop in Objective C that you are unable to utilize Fast Object Enumeration, you are looking at a serious performance hit. Dispatch / Delegate respondsToSelector / and other Objective C base language constructs give you a real disadvantage here.

I'm not going to go into dispatch, but the crux is, whenever you access something like this: "[zomg lolz]" you're handing off a method signature to the objective-c dispatcher to find the target C-function for your Objective-C method signature. This lookup process, when done over and over again, can dramatically reduce your performance.

If you're on an iPhone, go libxml2 and don't look back - but if your target machine has two processors and more ram than god, I'd go NSXMLParser for easier to maintain code.

Alex C Schaefer
+1  A: 

If you want to use libxml2 with an Objective-C front, take a look at this useful set of wrapper functions.

You issue an Xpath query to your XML document object and get back Foundation class objects: NSArray, NSString, and NSDictionary.

These functions help unite the speed of libxml2 with the readability of Objective-C code.

Alex Reynolds