XmlParserNSXMLParser - a class that performs a NSXMLParser-based parsing of the XML. The idea was to provide ViewController a unified interface for parsing XML, regardless of which XML parsing engine/technique was used. XmlParserDelegate - a simple protocol that the two XML parsing classes (listed below) conform to.
ViewController - a simple view controller class with two buttons that initiates the two types of XML parsing. You do this by selecting your app's target in the top of the left side "Navigation" panel, selecting the "TARGET" for your app, clicking on the "Build Settings" tab, finding the entry for "Header Search Paths", double clicking on that, clicking on the "+" button and adding an entry for " $SDKROOT/usr/include/libxml2" (without the quotes).ĪppDelegate - the standard app delegate class. You do this by selecting your app's target in the top of the left side "Navigation" panel, selecting the "TARGET" for your app, clicking on the "Build Phases" tab, expanding the "Link Binaries with Libraries" section, clicking on the "+" button, and choosing the libxml2.dylib library.Īdd the libxml2 headers you your search path. In order to use the LibXML2 parser, you must:Īdd the libxml2.dylib to your project. My particular implementations certainly have opportunities for further optimization, but hopefully it illustrates the nature of the difference.Īs a data point, with a 56mb XML file, the NSXMLParser implementation had a maximum footprint of between 100-200mb, whereas the LibXML2 implementation had a maximum footprint of less than 2mb. In this project, I've tried to isolate this logic in a single method (in my case, the view controller), leaving fairly minimalist XML implementations. Personally, I think the particular implementation in that project is a little questionable, with model-related logic embedded in both the view controller as well as the two XML classes. Anyway, this sample project demonstrates the two parsers, so one can compare and contrast the memory footprint of the two techniques. While this NSURLConnection technique is not easily done with NSXMLParser, it's quite simple with the LibXML2 parser. In Apple's XMLPerformance sample project, though, they demonstrate how one can take advantage of the streaming possibilities offered by NSURLConnection in conjunction with the LibXML2 XML parser to minimize the memory footprint. This appears to be true whether one uses the initWithContentsOfURL, initWithStream, or (obviously) initWithData. In practice, though, it seems to be aggressive about trying to load as much of the XML file into memory at any given time. The nature of the interface might lead one to assume that, especially as a SAX parser, that it might be conservative in terms of the memory footprint. Notably, the Cocoa iOS XML parser, NSXMLParser suffers from this problem. measured in tens or hundreds of megabytes), this becomes problematic. Most XML files are reasonably small, so this generally isn't an issue. When an app is parsing some server-based XML file, many implementations will simply load the entire XML file into memory before attempting the parsing the file. This answer was inspired by Apple's XMLPerformance sample code, which illustrates the two different XML parsers, LibXML2 and NSXMLParser.
BASE64 XML DECODE HOW TO
This demonstrates how to use LibXML2 to parse a very large XML file as it is being streamed from a web server, avoiding the problems introduced by NSXMLParser which has a tendency to load the entire (or at least very large portions) of an XML file into memory before initiating the XML parsing process. This is an iOS application, created in response to a question on Stack Overflow, Decoding a HUGE NSString, running out of memory.
0 kommentar(er)
