Better performance with libxml2 or NSXMLParser on iPhone?

Question

I'm curious that your solution is for high-performance XML parsing on iPhone, given the limited amount of processor power. I looked at the XML performance application that Apple provides as a demo, and it seems that for the data feed (300 iTunes songs) they are disassembling .. libxml2 always seems to be a winner.

With your data experience, 100Kb, what do you prefer for optimal performance? I am currently using TouchXML + libxml2 and see if the parsing speed can be optimized as is.

Thanks for the feedback!

Answer 1

I usually found for large pieces of data (for example, the apple example that you are linking to) libxml2 tends to be faster. For smaller pieces of data, the difference is negligible. One of the advantages that I like about NSXMLParser is that it is an Objective-C based implementation of an XML parser, where libxml2 is based on C.

Answer 2

You can always take a look at my replacement for NSXMLParser. It reads the XML data from the stream, but does not store everything in memory, and transfers it 1 Kbyte at a time to libxml (where NSXMLParser transfers everything at once).

The source code is available on github , and my post on memory aspects is on my blog .

Answer 3

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

NSXMLParser is generally prettier. The code makes sense, since there should be a sax parser, and this is a real Cocoa class with all conventions. If usability and clean code are your top priorities, you should stick with NSXMLParser.

While NSXMLParser uses libxml2 on the backend, it is slower due to the bases of Objective-C and the Achilles heel of Objective-C. When parsing XML, you basically just do a bunch of hard loops over and over again to find the tags you are interested in.

This is the lesson - when you cannot use Fast Object Enumeration in a narrow Objective-C loop, you are looking at a serious performance hit. Submission / Delegation responds to the Selector / and other Objective-C base language constructors, which gives you a real flaw.

I'm not going to enter the newsletter, but the bottom line is that when you access something like this: "[zomg lolz]" you pass the method signature to the Objective-C dispatcher to find the target C function for your Objective-C signature . This search process, when performed over and over again, can significantly reduce performance.

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

Answer 4

I tried my data (about 600 records) using an Apple parsing application. Found libxml2 much faster than NSXMLParser. I switched to libxml2 (although I find it more difficult to implement than NSXMLParser, it works well for my purpose)

In the same example, which tried about 100 records, there is not much difference in both implementations.

Answer 5

libxml2 will always be faster than NSXMLParser. NSXMLParser gives you a decent event-bsaed API, but it is built on top of libxml2 and also not based on threads (for example, NSXMLParser passes the entire data block to libxml2 at once).

If you are optimizing speed, libxml2 is definitely the way to go. However, if you want to use an object-based API and don't care about performance, NSXMLParser is the right tool for the job. And note that NSXMLParser is not necessarily slow, it is not as fast as libxml2.

Answer 6

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

You send an Xpath request to an XML document object and return Foundation objects: NSArray , NSString and NSDictionary .

These features help combine the speed of libxml2 with the readability of Objective-C code.

Answer 7

libxml2 is faster than NSXMLParser and also more flexible. It also has a very small (but noticeable) memory leak with the xmlReader interface (my favorite set interface) in the SDK released with iPhone OS 2.2.1. Details built into http://inessential.com/2009/02/25/moving_to_libxml2_sax2 . Other interfaces in libxml2 do not have this problem - it just happens to be my favorite.

Functionally, you won't notice the difference with a relatively small amount of XML, but if you find yourself wading through a large set passed to the parser, it will become noticeable.

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

Answer 8

I used Objective-Xml. This is another replacement for NSXMLParser. This gave me about a 15 second file improvement, which took 1 minute to parse. Still too slow.