This is not LISP

Patrick Logan counters complaints about LISP's syntax with the following example of LISP's power:

(apply + (take 1000 (iterate inc 1)))

Hmm..I find the following preferable:

(1 to: 1000 ) reduce + 0

iPhone XML: from DOM to incremental SAX

In my last post, I extended Ray Wenderlich's XML parser comparison to MAX, and performance seemed to be about 2x better than the nearest competitor, TBXML and around 7x faster than NSXMLParser, Cocoa Touch's built-in XML parser.

While the resulting code has been posted here, I haven't yet explained how I got there.  First, I downloaded both Ray's project and Objective-XML 5.3.   iPhone OS requires a bit of trickiness to get a reusable library, partly due to the fact that frameworks or dynamic libraries are not supported, partly due to the fact that simulator and device are not just different Xcode architectures of a single SDK, and not even just different SDKs, but actually different platforms.  If anyone can tell me how to create a normal target that can compile/links for both the simulator and the device, I'd love to hear about it!

So, in order to compile for iPhoneOS, you'll need to select the iXmlKit target:

You'll need to build twice, changing Active SDK settings once to the the device and once to the simulator.  You will then have two copies of the libiXmlKit.a library, one in the directory Release-iphoneos, the other in Release-iphonsimulator (both relative to your base build directory):

 

marcel@mpwls[LD]ls -la ~/programming/Build/Release-iphoneos/ 

-rw-r--r--   1 marcel  staff   521640 May  9 19:52 libiXmlKit.a

 

These two copies then need to be joined together using the  lipo command to create a single library that can be used both with the simulator and the device.

lipo -create Release-iphoneos/libiXmlKit.a Release-iphonesimulator/libiXmlKit.a -output  Release/libiXmlKit.a

(Newer Objective-XML versions will have a shell-script target that automates this process).  Once I had the fat libiXmlKit.a library, I created a new MAX group in the XMLPerformance project, and copied both the library and the MAX header file into that group:

 

I then created a new MAX Song parser class:

#import "iTunesRSSParser.h"
 
@interface MAXSongParser : iTunesRSSParser {
   id parser;
   NSDateFormatter *parseFormatter;
}
@end

The implementation is also fairly straightforward, with your basic init method:

 
#import "MAXSongParser.h"
#import "MPWMAXParser.h"
#import "Song.h"
 
@implementation MAXSongParser
 
-init
{
    self=[super init];
    parseFormatter = [[NSDateFormatter alloc] init];
    [parseFormatter setDateStyle:NSDateFormatterLongStyle];
    [parseFormatter setTimeStyle:NSDateFormatterNoStyle];
    MPWMAXParser *newParser=[MPWMAXParser parser];
    [newParser setUndefinedTagAction:MAX_ACTION_NONE];
    [newParser setHandler:self forElements:[NSArray arrayWithObjects:                 @"item",@"album",@"title",@"channel",@"rss",@"category",nil]
               inNamespace:nil prefix:@"" map:nil];
    [newParser setHandler:self forElements:[NSArray arrayWithObjects:
                 @"releasedate",@"artist",@"album",nil]
             inNamespace:@"http://phobos.apple.com/rss/1.0/modules/itms/" 
             prefix:@"" map:nil];
    parser=[newParser retain];
   return self;
}

The MAX parser is initialized in this init method.  We define the elements we care about using the two "setHandler:forElements:inNamespace:prefix:map:" messages, one for each namespace we will be dealing with.  In the default (RSS) namespace, we are interested in the "item", "album", "title", "channel", "rss" and "category" elements.  In Apple's special "itms" namespace, we will handle "releasdate", "artist" and "album".  Setting MAX_ACTION_NONE as the undefined tag action means that the parser will ignore elements not listed as interesting and all their sub-elements.

Songs are created in the -itemElement:... method, which turns the relevant child-elements of the item element into Song attributes:

-itemElement:children attributes:attributes parser:parser

{

   Song *song=[[Songalloc] init];

   [song setAlbum:[children objectForUniqueKey:@"album"]];

   [song setTitle:[children objectForUniqueKey:@"title"]];

   [song setArtist:[children objectForUniqueKey:@"artist"]];

   [song setAlbum:[children objectForUniqueKey:@"album"]];

   [song setCategory:[children objectForUniqueKey:@"category"]];

   [song setReleaseDate:[parseFormatter dateFromString:[children objectForUniqueKey:@"releasedate"]] ];

   return song;

}

Two more methods make the actual parse process complete:  <channel> elements have one or more <item> elements, so we want to return all of them, using "objectsForKey:":

-channelElement:children attributes:attributes parser:parser

{

  return [[children objectsForKey:@"item"] retain];

}

Finally, there are a bunch of elements that we have defined interest in but treat identically...these can be handled using the "default" element handler:

 

-defaultElement:children attributes:attributes parser:parser

{

  return [[children lastObject] retain];

}

 

That concludes the routines that actually parse the XML into objects, now for kicking off the parser. With the timing code removed, the method is fairly straightforward:

 

- (void)downloadAndParse:(NSURL *)url {

   id pool=[NSAutoreleasePool new];

   [parserparse: [NSData dataWithContentsOfURL:url]];

   for ( id song in [parserparseResult] ) {

       [self performSelectorOnMainThread:@selector(parsedSong:)

             withObject:song waitUntilDone:NO];

   }

   [pool release];

}

With the timing code, it all gets a bit messier:

 

- (void)downloadAndParse:(NSURL *)url {

   id pool=[NSAutoreleasePool new];

   [self performSelectorOnMainThread:@selector(downloadStarted) withObject:nil waitUntilDone:NO];

   NSData *data=[NSData dataWithContentsOfURL:url];

   [self performSelectorOnMainThread:@selector(downloadEnded) withObject:nil waitUntilDone:NO];

   NSTimeInterval start = [NSDate timeIntervalSinceReferenceDate];

   [parserparse:data];

   for ( id song in [parserparseResult] ) {

      [selfperformSelectorOnMainThread:@selector(parsedSong:) withObject:song waitUntilDone:NO];

   }

   NSTimeInterval duration = [NSDatetimeIntervalSinceReferenceDate] - start;

   [selfperformSelectorOnMainThread:@selector(addToParseDuration:) withObject:[NSNumbernumberWithDouble:duration] waitUntilDone:NO];

   [selfperformSelectorOnMainThread:@selector(parseEnded) withObject:nilwaitUntilDone:NO];

[[NSURLCachesharedURLCache] removeAllCachedResponses];

 [pool release];

}

 

This produces a non-incremental DOM-style parser, so we first download the data, then process it into a DOM and finally transfer the processed objects to the main thread for display.  It differs from other DOM-syle XML parsers in that it actually produces domain objects (as a Domain Object Model parser arguably should), rather than a generic XML DOM that must then be converted to objects.

Turning the DOM-style parser into a SAX-stye parser is almost completely trivial.  Instead of returning the Song objects at the end of itemElement:..

 

   [song setReleaseDate:[parseFormatterdateFromString:[children objectForUniqueKey:@"releasedate"]] ];

  return song;

}

 

 

we instead pass them to the delegate there and return nil so no tree is constructed:

   [song setReleaseDate:[parseFormatterdateFromString:[children objectForUniqueKey:@"releasedate"]] ];

[self performSelectorOnMainThread:@selector(parsedSong:)

withObject:song waitUntilDone:NO];

[song release];

return nil;

}

 

This means we can also remove the "channelElement" method and the for loop in downloadAndParse: that passed the Song objects to the main thread.  This is a SAX-style parser (though it doesn't use the SAX methods and does produce domain objects), but it is still non-incremental because it first downloads all the data and then parses it.  If we want to turn the SAX parser into an incremental parser that overlaps processing with downloading, there is one final tweak that fortunately further simplifies the downloadAndParse method (again with timing code removed):

 

- (void)downloadAndParse:(NSURL *)url {

   id pool=[NSAutoreleasePoolnew];

  [parserparseDataFromURL:url];

   [[NSURLCachesharedURLCache] removeAllCachedResponses];

   [pool release];

}

While this is probably best not only in terms of performance and responsiveness, but also in terms of code size, it doesn't play well with the XMLPerformance example, because there are no external measurement hooks that allow us to separate downloading from parsing for performance measurement purposes.

In addition, the XMLPerformance example is odd in that is both multi-threaded and measure real time rather than CPU time when measuring parse performance.  The reason this is odd is that when both parsing and display are active, the scheduler can take the CPU away from the XML parsing thread at any time and switch to the display thread, but this time will be counted as XML parsing time by the measurement routines.  This is obviously incorrect and penalizes all the incremental parsers, which is why Ray's comparison showed all the DOM parsers as performing better than the SAX parsers.

I hope these explanations show how to create different styles of parsers using MAX.

 

 

 

 

iPhone XML Performance Revisited

Ray Wenderlich has done a great comparison of iPhone XML parsers, using the same sample I had looked at earlier in the context of responsiveness.

 

As Ray was comparing performance, my hobby-horse, I was obviously curious as to how MAX stacked up against all the upstart competition. Quite well, as it turns out (average of 5 runs on an iPad with 3.2):

---

Figure 1: total times (seconds)

---

MAX was about 50% faster than the closest competition, TBXML, at 0.43s vs. 0.61s.

 

However, the XMLPerformance sample is a bit weird in that it measures elapsed time, not CPU time, and is multi-threaded, updating the display as results come in.

 

In order to account for this overhead that has nothing to do with the XML parsers, I added a "Dummy" parser that doesn't actually parse anything, but rather just generates dummy Song entries as quickly as possible. This takes around 0.2 seconds all by itself. Subtracting this non-XML overhead from the total times yields the following results:

---

Figure 2: XML parse times (seconds)

---

When measuring just the XML parsers themselves, MAX is around twice as fast as the closest competition and seven times as fast as the built in NSXMLParser.

 

Sweet.

[Update]  I forgot the link to where I had uploaded the source: XMLPerformance.tgz at http://www.metaobject.com/downloads/Objective-C/

This blog has moved

This blog is now located at http://metaoblog.blogspot.com/. You will be automatically redirected in 30 seconds, or you may click here. For feed subscribers, please update your feed subscriptions to http://metaoblog.blogspot.com/feeds/posts/default.

Objective-XML 5.3

New in this release:

• Cocotron targets for Windows support.
• XMLRPC support.
• No longer uses 'private' API that was causing AppStore rejections for some iPhone apps using Objective-XML.
• Support for numeric entitites.

http://www.metaobject.com/downloads/Objective-C/Objective-XML-5.3.tgz.