XMLPerformance Test App Extended To Compare 3rd Party Libraries
There are a lot of options when it comes to parsing XML on the iPhone. The iPhone SDK comes with two different libraries to choose from, and there are several popular third party libraries available such as TBXML, TouchXML, KissXML, TinyXML, and GDataXML. How is a developer to choose?
I have been recently taking a look at the various options out there, and ended up extending the XMLPerformance sample from Apple to try out each of the above libraries to learn how they worked and compare their performance. I thought I’d share what I’ve learned thus far to others who might be searching for the best XML library for their iPhone project.
In this article we’ll give a detailed comparison of the features and performance of the most popular iPhone libraries, explain how to choose between them, and give a sample project showing how to read XML data using each of the above libraries.
SAX vs. DOM
Before we begin, I wanted to make sure everyone is aware of the most important difference between XML parsers: whether the parser is a SAX or a DOM parser.
- A SAX parser is one where your code is notified as the parser walks through the XML tree, and you are responsible for keeping track of state and constructing any objects you might want to keep track of the data as the parser marches through.
- A A DOM parser reads the entire document and builds up an in-memory representation that you can query for different elements. Often, you can even construct XPath queries to pull out particular pieces.
Ok, now let’s discuss some of the libraries!
The Most Popular XML Parsers for the iPhone
In my research, here’s what seemed to me to be the most popular XML Parsers for the iPhone, and a brief description of each one:
- NSXMLParser is a SAX parser included by default with the iPhone SDK. It’s written in Objective-C and is quite straightforward to use, but perhaps not quite as easy as the DOM model.
- libxml2 is an Open Source library that is included by default with the iPhone SDK. It is a C-based API, so is a bit more work to use than NSXML. The library supports both DOM and SAX processing. The libxml2 SAX processor is especially cool, as it has a unique feature of being able to parse the data as it’s being read. For example, you could be reading a large XML document from the network and displaying data that you’re reading for it to the user while you’re still downloading.
- TBXML is a lightweight DOM XML parser designed to be as quick as possible while consuming few memory resources. It saves time by not performing validation, not supporting XPath, and by being read-only – i.e. you can read XML with it, but you can’t then modify the XML and write it back out again.
- TouchXML is an NSXML style DOM XML parser for the iPhone. Like TBXML, it is also read-only, but unlike TBXML it does support XPath.
- KissXML is another NSSXML style DOM XML parser for the iPhone, actually based on TouchXML. The main difference is KissXML also supports editing and writing XML as well as reading.
- TinyXML is a small C-based DOM XML parser that consists of just four C files and two headers. It supports both reading and writing XML documents, but it does not support XPath on its own. However, you can use a related library – TinyXPath – for that.
- GDataXML is yet another NSXML style DOM XML parser for the iPhone, developed by Google as part of their Objective-C client library. Consisting of just a M file and a header, it supports both reading and writing XML documents and XPath queries.
Ok, now let’s start comparing all these libraries!
XML Parser Performance Comparison App
Apple has made an excellent code sample called XMLPerformance that allows you to compare the time it takes to parse a ~900KB XML document containing the top 300 iTunes songs with both the NSXML and libxml2 APIs.
The sample allows you to choose a parsing method and then parse the document, and it keeps statistics on how long it took to download the file and parse the file in a database. You can then go to a statistics screen to see the average download and parse times for each method.
I thought this would be an ideal way to test out how these various APIs performed against each other, so I extended the sample to include all of the above libraries. You can download the updated project below if you want to try it out on your device. It also serves as a nice example of how to use each of the above APIs!
Download Updated XMLPerformance Project
A note on the project: if the library included XPath support, I used it for a single lookup, because I felt it represented the way the library would be used in practice. But of course XPath is generally slower than manually walking through the tree, so it adds to the benchmarks for those libraries.
So anyway – I’ll discuss the results of how things performed on my device here with the sample written as-is – but feel free to give it a shot on your device, or tweak the code based on the actual XML data you need to parse!
XML Parser Performance Comparison
Here’s some graphs that shows how quickly the various parsers parsed the XML document on my device (an iPhone 3Gs):
As you can see here, NSXMLParser was the slowest method by far. TBXML was the fastest, which makes sense because many features were taken out in order to optimize parse time for reading only.
I was surprised, however, to see that TBXML and some of the other DOM parsing methods performed faster than libxml2′s SAX parser, which I had thought would be the fastest of all of the methods. I haven’t profiled it, but my guess as to why it is slower is because of the frequent string compares needed to parse the document in the SAX method.
However, don’t discount libxml2′s SAX method by looking at this chart. Remember that libxml2 is the only one of these methods that can parse the document as it’s reading in – so it can let your app start displaying data right away rather than having to let the download finish first.
Ok, here’s a graph that shows the peak memory usage by parser (this was obtained through running the various methods through the Object Allocations tool):
Note that the DOM methods usually require more memory overhead than the SAX methods (with the exception of TBXML, which is indeed quite efficient). This is something to consider when you are dealing with especially large documents, given the memory constraints on an iPhone.
Also note that libxml2′s SAX method is the best option as far as peak memory usage is concerned (and I suspect it would scale better than the others as well).
Finally, let’s wrap up with a chart that summarizes the differences between the parsers and everything we’ve discussed above:
| NSXML | libxml2 – SAX | TBXML | TouchXML | KissXML | TinyXML | GDataXML | libxml2 – DOM | |
|---|---|---|---|---|---|---|---|---|
| Included with SDK? | Yes | Yes | No | No | No | No | No | Yes |
| Seconds to Parse | 1.87 | 1.19 | 0.68 | 1.1 | 1.37 | 1.27 | 1.07 | 0.84 |
| Peak Memory Usage | 3.11 | 3.01 | 3.07 | 6.5 | 5.25 | 4.8 | 4.15 | 4.97 |
| Parse While Downloading? | No | Yes | No | No | No | No | No | No |
| Edit/Save XML? | No | No | No | No | Yes | Yes | Yes | Yes |
| XPath Support? | No | No | No | Yes | Yes | Yes* | Yes | Yes |
| C or Obj-C | Obj-C | C | Obj-C | Obj-C | Obj-C | C | Obj-C | C |
| License | Apple | MIT | MIT | MIT | MIT | ZLib | Apache | MIT |
* = with TinyXPath
Which To Choose?
Which XML parser to choose really depends on what you want to do with the parser.
- If you just want to read small XML documents, performance doesn’t matter as much with small documents. You probably want to pick something with XPath support and something that is written in Objective-C to make your job easier. So I’d recommend either TouchXML, KissXML, or GDataXML for this case.
- If you want to both read and write small XML documents, again performance doesn’t matter as much as functionality and ease of use. You probably want to pick something with XPath support, written in Objective-C, with read/write capability. So I’d recommend KissXML or GDataXML for this case.
- If you want to read extremely large XML documents, performance is the critical issue here. You’ll want to consider libxml2 SAX, TBXML, or libxml DOM for this, depending on what your exact situation is.
What about the ones I didn’t mention?
- NSXML is a decent choice if you’re dealing with relatively small documents, and you don’t feel like adding a third party library to the SDK.
- TinyXML could be an OK choice for medium sized documents if you already have experience with the API and are comfortable with C as it ports quite easily over to the iPhone.
I took a look at two other XML libraries during the course of this investigation (VTD-XML and Objective-XML), but I couldn’t get them working. If someone else has had more luck with these, feel free to extend the sample project to include them!
Where To Go From Here?
If you’re looking for some help using one of these libraries, check out my post on How to Read and Write XML Documents with GDataXML.
And if anyone has any additional feedback about these libraries or tips that may help other developers, please chime in below!
Category: iPhone
Loading ...
This is a *great* roundup, thanks! We’ve been using TouchXML for some simple XML parsing and XPATH stuff in our apps, and it seems to work well enough – although it appears it hasn’t been updated in a while and it could use some cleaning up / additional features.
Thanks very much for sharing this.
What about using a NSMutableDictionary, or NSArray to initWithContentsOfFile from a plist.
I wonder what the stat is on that. You could mimic a plist returned from a server or local to the bundle.
How about APXML? I’ve just started using it, and it’s working *great*! http://arashpayan.com/blog/index.php/2009/01/14/apxml-nsxmldocument-substitute-for-iphoneipod-touch/
Hi, i’m becomming a fan of your post, did almost every How To… from the cocos2D application, and i’m actually in an internship for my last school year (at least i hope :D) and i’m making a game fort iPhone/iPod touch.
we are for the moment looking for an XML Parser, and i think i’ll use KissXML for what i need, but i can’t find any tutorial and the documentation is very poor, may you have any toturial or website with documentation to share? that would be awesome.
Thank you Very much for all your tips and post here, that’s very interresting and they are really nicely explained. Continue that work, it’s really Great.
Saliom.
@Saliom – thanks! I’d recommend checking out the sample project in this tutorial, it shows you a working example of using KissXML that you can use as a basis.
I’ve also been considering writing a tutorial on how to use one of these XML parsers in the future – let me know if you think that would be useful or not, and if so specifically what type of information you think would be useful.
Yeah a tutorial on that would be nice i think.
About the information, to begin i’d say how does it work?
How to parse our own XML file with our own Elements and their attributes?
How to make an object from en Elements we got from our XML file?
How to Query when you use a DOM style parser, and how to do an xPath Query also, and also why not explain the difference between a query and a xPath query ( i don’t really know what’s the difference :/ )
so i think the things that are most used would be good information :)
(I’ve read the sample, but didn’t really understand everything, the comments help a bit but they aren’t enough for my little brain to understand while when you do a tutorial you explain everything very clearly which makes my brain able to understand :D
well, i will try to parse some file on my own, but if you do a tutorial i’ll read it for sure =D)
oups, Forgot to say that it would be even nicer for me if you could do the tutorial with KissXML since i’ll be using it :p :D
and also for the needed information, maybe a little example on how to write/edit and save a file with the parser, i don’t think that it’s in the sample project :)
Saliom.
@Saliom – Great, thanks for the ideas, much appreciated! I am much more likely to write such a post now :]
héhé Thanks to you for all your explanations :) :D Already looking foorward for that post :D
Thanks for the comparision another one you might want to take a look at is AQXMLParser http://quatermain.tumblr.com/post/93651539/aqxmlparser-big-memory-win
Hi Ray! Thanks for great article, never thouight that there are so many ways for XML on iPhone.
I’ve looked through GDataXML code and found that it’s based on libxml2, looks like objc wrapper class. Very interesting that the peak memory usage of plain libxml2 is bigger… Will try your code on my mac when come back home.
Since there are different xml parsers available for my iPhone projects, it proves that NSXMLParser needs to be optimized to clear the mess.
so r u updating it?????
Hi Ray! Thanks for that great comparison of the different ways of accessing XML on the iPhone.
I’m developing an App that will communicate with a webserver through a web service so I’ll also have to go through creating XML Requests and parsing the results.
I think I’ll take a shot at GDataXML but I’d love to take a look into your extended performance comparison app, but unfortunately it seems to be offline at the moment.
Anyways, thanks for the roundup, much appreciated. :)
Dear Ray! Your Updated XMLPerformance Project could not be found any longer [404]. Wanna take a look on the code.
Thanks guys, I just moved to a new web host and had forgotten to move that directory! Should be fixed now.
Thanks for the comparison. I have 2 questions:
1. From the difference you have provided between SAX and DOM, I understood that with DOM, XML need not be converted into class and that the DOM parser handles the storage of the xml. Is this understanding right?
2. To display the xml elements into Tableview of IPhone, is there a direct binding available, or is the XML conversion to class, followed by the class binding to UI elements the only mechanism?
3. I checked out the sample code on the tbxml site, which showed parsing every element and then adding it to the related property of the class. Can the full xml node be mapped to a class automatically, rather than the extraction of every element? Basically, are there any short cuts :-)
Thanks once again for the very extensive and clear comparison.
1) Yes, a DOM parser will build up the entire structure of the XML document into an in-memory tree of XML nodes. So in theory, you could just work with the DOM document directory and pull out the various pieces when you need it.
However, in practice a lot of times it’s more useful to translate the tree into your own object hierarchy so you have easier access / can define your own methods on the objects / have type safety / etc.
2) Apple has a technology called Cocoa Bindings that does this kind of thing, but unfortunately it is not available on the iPhone.
3) I know what you mean, I am a big fan of technologies such as .NET’s XMLSerializer. However, AFAIK there is no comparable technology available for the iPhone.
Best of luck!
Hi,
I am getting huge xml file (1.7 mb) from server, through socket to my iPhone. data are coming in chunks. is there a way i can parse such a big xml file in faster way?
thanks
Jeet
Hi Ray,
great article! Your puzzlement at the seeming performance advantages is entirely justified: not only should the DOM parsers not be faster (in general), they actually aren’t. The apparent performance advantage in the example is not real, it is an artifact of how the XMLPerformance app is structured that hugely penalizes incremental parsers.
I have a parser that I can easily switch from being SAX-like to being DOM-like, and it gained a 2x speed increase from going to DOM, whereas there should have been at most a trivial difference, and if anything in the other direction.
I don’t yet know exactly what the cause of this is, but I am pretty sure it has to do with the fact that XMLPerformance sends songs to the main thread for display and does this one song at a time. Depending on the timing of your songs, that can get you more or fewer screen updates while your parser is running. In addition, some of the timing is also done using the main thread, while other timing is mixed between the two.
I did a previous analysis of XMLPerformance here.
Cheers,
Marcel
xml sucks
@jeet – For very large files, I’d recommend the libxml2 – SAX method since you can read it as you are downloading the file.
@Marcel – Great comment, and nice post. Yeah you would think the example would have been structured to show off the advantages of SAX a bit better!
I have published an updated comparison that takes some of the overhead into account (but doesn’t yet deal with the SAX/DOM issue).
Tnahks for all your tutorials on here! Have you thought about comparing the performance of these vs parsing similar data in json format? Using the touchjson lib or the other popular one on google code?
previously i used NSXML parser later onwards using only libxml2 SAX parser in my apps, because of parsing while downloading and storing to database is much efficient way to manage memory of app.
I took your sample project and loaded to my iPhone 3G (not the 3Gs) and the TouchXML actually parses slower than LibXML2, and LibXML2 DOM is faster than libXML2 SAX.
Great article..many thanks for making things clearer
this is nice article and helpful. Thanks a lot.
Before anyone else wastes their day on this like I did — TBXML is pretty poorly written, and very easy to crash. Feed it “.
Looks like my example XML was eaten from the previous comment. Try starting a new XML comment, and then not ending it (TBXML will crash).
@Craig: Good to know! However to give TBXML some credit, it was designed specifically to make some assumptions that the XML was valid/well formed so it could go as quickly as possible. So it could be particularly useful if the XML comes from a controlled source – like yourself if you ship XML with the app! But if that assumption can’t be made, TBXML probably isn’t the way to go.
Thnxs nice share… best comparison … i like that and the most thing like that is that which is that source code is also providing.
Thanking in advance:
Muhammad Kalim
iPhone Application Developer
Thanks for the great comparison. Does anyone know if any of these libraries are not acceptable for app store submission?
@Mike: AFAIK any of these libraries should be fine for app store submission.
Hi Ray!
Nice article :) It is easy to read and well written/layout. Thank for your efforts!
What do you mean exactly with small sized, or medium sized or extremely large sized XML files?
Is it the file size of the XML document? Then an approximately file size would help me a lot.
Or is it the number of lines? Here again I would like to have a number.
Cheers,
testing
@testing: Thanks for the kind words!
Regarding file sizes (yeah I’d use file size rather than number of lines) – I haven’t run the numbers on this so take these with a grain of salt – but if a document is < 50K I'd consider it small, >= 500K large and worth checking out the performance implications, and medium inbetween.
Hi Ray,
thank you for answering my question. To play it safe I ask you if with K “Kilobyte” is meant (However, I think it cannot be any other way).
Thanks again
testing
@testing: Yep you are correct!
Hi,
we are planning to use KissXML for our application and going to post our app to the App Store in future, want to know like usage of 3rd party libraries like KissXML, any chances of being rejected by the App Store..please let me know.
Thanks
Nagaraj
Don’t know about KissXML, but there have been several successful submissions with Objective-XML.
@Nargarajan: I don’t think you’ll have any problems, usually Apple doesn’t care if you use 3rd party libraries as long as they don’t use any undocumented Apple APIs.
Awesome, makes my job much easier – thanks!
Which parser parse the string “Szállító”. I tried with NSXMLParser. but it didnt parse the above specified strng.. Any suggestions ?
@david: You could try downloading the above project and modifying it to read your own XML file to test out each one. Not sure why NSXMLParser wouldn’t work though, as long as the file is UTF-8 encoded…
I read the tutorial for GDataXML it it would appear that it was designed to read the entire xml file into memory and then parse.
Which of the libraries would allow us, to go directly to a node if we know the index beforehand–of course I understand that the parser would still need to crawl the nodes until it reached the desire location but not use up memory while doing so.
Any thoughts?
Manny
Great Article! Your GDataXML tutorial is great! Thanks for the roundup.
@Mtran003: You are correct, GDataXML and all DOM parsers read the entire XML document into memory. If you have a large document where conserving memory is important, you’ll probably want to use a SAX parser like NSXMLParser or libxml2, which will allow you to pull out just the info you’re interested in.
@Nathan: Thanks glad you liked the tutorials!
this is nice example attached here
It’s a great post!
Great article Ray. It is more useful.
Probably should include expat in this comparison as well since it’s also available on the iphone. It’s considered the fastest available (last time I checked anyway). I use it in most of my projects. It’s SAX only.
wonderful article. I like it..
this is very nice doc i am thank that you share this info to us thank you very much
Indeed, great article on xml parser for iphone project, especially for newbies like me :P
Thanks~
Wow thanks everybody! Really glad you like it.
wouhou thx for that tutorial
This is really fantastic stuff. Thanks for posting.
I have an opportunity to define an app’s data as either JSON or XML. Any thoughts on comparing the performance of these XML parsers to the JSON parsers using the exact same dataset?
@suchita: Hehe thanks!
@Mark: I’m probably unlikely to update this for that (but if you want to, go ahead and I’ll post up any updated ver!) :] But I suspect in most cases you’ll find JSON faster to parse than XML – and .plist parsing even faster than either JSON or XML.
nice
Thanks!
Thanks 4 the information
Thanks for your series of tutorials, they did help a lot.
Can you write another article to discuss about different SQLite wraps? (such as performance, memory usage, etc.)
nice work.
how to use tinyXML parsing for retreiving data from server??
Nice job, this research is very useful to decide which xml parser use, especially when you have an idea of the kind of xml you are going to parse. In my case, i started with NSXML just because i wont include third part libraries, and i would like to study the ios, but the xml is quite small, and i needed to match elements that were very far from the root, so i decided to use a DOM model to parse with XPath support. It was a good decision, because performance really does not matter in this case, and my job to develop was easier than NSXML or any other SAX parser approach.