»You get great software, Haiti gets financial help in its time of crisis.«

Turn on your volume, and… Buon appetito!

Spots currently contains hotspot locations of the following providers:

• Free US locations: 13,000+ (NEW)
• T-Mobile US: 2,500 (NEW)
• T-Mobile EU: 12,000 (updated)
• AT&T: 18,000+ US locations (updated)
• BT FON: 80,000 in the UK (NEW)
• Neuf FON: 60,000 in France (NEW)
• FON: 200,000 worldwide locations (updated)
• BT Openzone: 3,200 UK and IR locations (updated)

And we are planning to add more hotspots soon.

Using Objective C++ to enhance the performance of iPhone applications.

One thing I really like about software development is, that there are problems from so many different domains—and problem solving is, when the fun part starts. While developing Spots, I have been confronted with UI decisions over and over. Designing a streamlined user interface for the iPhone is not easy. »Shall I include a button for the provider filter or put it into the Settings.app?« I changed my mind on this about twenty times.

This post will not be about user interface but about coding and performance. One of the hardest problems to solve was the drawing of the map (the rectangle in the lower part of the screen). It took me several approaches to learn that the only way to draw 230,000 spots on the map was using OpenGL and a lot of tricks and cheats to make drawing performance acceptable. At last I used three different techniques depending on the zoom level and amount of visible spots. Performance was the most important issue, since I wanted map interaction (dragging and pinching) to be as smooth as possible, ideally at 60Hz.

In this article, I want to share some of the techniques used to improve performance. They are very simple and straight forward but I took the time to write them down because I see them rarely used in a Cocoa context. For example, I’m not seeing a lot of C++ in Cocoa, even though both languages can be mixed in a very productive way. Objective C++ is a great extension to pure Cocoa when your aim is performance. And on the iPhone, everything is about performance.

The Problem

Spots contains about 230,000 hotspot locations, spread over a rectangular area (the world map in mercator projection). It is necessary to count the number of visible spots in the area covered by the current map rectangle, since this value decides which drawing technique to use. The coordinates are normalized, so the whole world covers the rectangle {{0.0, 1.0}, {0.0, 1.0}}. For a typical use of the program, the map rectangle is quite small: less than two percent of the whole map width or height.

How do I count the number of locations in a database of hundreds of thousands of locations efficiently?

I prepared an XCode project that contains all code discussed here. The example project does not contain the original database that comes with Spots. It simply spreads out the spots randomly over the world map, which is very different from the real scenario. But the stats I collected with the original data are very much the same like those from the random data.

The first Approach: Plain-vanilla Cocoa

The first approach is very simple and does not even try to be very efficient. The locations are represented as Objective C objects (@class Spot) and are kept in a database object (@class SpotsDB1) using an NSArray.

@interface Spot : NSObject {
    CGPoint _position;
}
@property (nonatomic) CGPoint position;
@end

@interface SpotsDB1 : NSObject {
    NSArray* _spots;
}
- (NSUInteger)countSpotsInRect:(CGRect)rect;
@end

To count the locations in a given CGRect, the database object simply iterates over the array and checks each location.

NSUInteger count = 0;
for (Spot* spot in _spots) {
    if (CGRectContainsPoint(aRect, spot.position))
        ++count;
}

With this code it takes about 250 milliseconds to count the number of spots in a {0.02, 0.02} random rectangle from a total of 230,000. Too bad, if you target a frame rate of 60Hz, where you have 16 ms to draw a frame.

What makes this solution slow is not only the lack of a smarter algorithm, but also the amount of time wasted to make a couple of function calls in the tight loop. Another negative impact on the performance is the fact, that the locations are stored in objects in an NSArray, since the large memory footprint of objects and the pointer indirection of the array all add to processing time.

The second Approach: Simple optimizations

To make the same solution run much faster, we can simply put the locations into a more compact data structure: a standard C array of CGPoint structs. For ease of use, we keep that C array in an NSMutableData object.

_spotCount = [spots count];
_spotsData = [[NSMutableData alloc] init];
for (Spot* spot in spots) {
    CGPoint p = spot.position;
    [data appendBytes:&p length:sizeof(CGPoint)];
}

Removing the function calls from the loop we get a times four performance boost:

CGFloat xMin = CGRectGetMinX(aRect);
CGFloat yMin = CGRectGetMinY(aRect);
CGFloat xMax = CGRectGetMaxX(aRect);
CGFloat yMax = CGRectGetMaxY(aRect);

CGPoint* begin = (CGPoint*)[_spotsData bytes];
CGPoint* end = begin + _spotCount;

NSUInteger count = 0;
for (CGPoint* i = begin; i != end; ++i) {
    if (i->x > xMin && i->y > yMin && i->x < xMax && i->y < yMax)
        ++count;
}

Without changing the simple algorithm, we now calculate the spot count in 55 milliseconds, which is more than four times faster. What’s even better, regarding the very constrained resources of the iPhone, is the fact, that we use less than half of the memory compared to the first version.

The third Approach: Algorithmic optimizations

Of course there are lots of clever ways to optimize lookup of points in a planar map. For example, you could use a quad tree to store the points. In this example I’m using a less complex solution, which does not imply a change to the way, the data is stored. And I’m using built-in features of C++ so that I don’t even have to write the small piece of code that gets a little more complex.

The idea is to sort the locations in the array from left to right. By doing that, it is possible to determine the left and right margins of the given rectangle very quickly (see below). When the margins in the array are known, only the points between the margins have to be checked.

So it’s all about finding the margins quickly. We do this by using binary search, which works on an array of sorted values. It does not check every value to find the matching position but jumps in the middle, checks if the value is less or greater, then jumps in the middle of the remaining section and so on. By using this cutting-in-half algorithm, binary search takes log2(n) checks to find the best element. With our array of 230,000 locations, that’s only 22 elements to try!

Back to the code, we find how easy it is to implement the above algorithm. Of course, now we have to sort our database:

// comparison function for array sorting
NSInteger leftToRight(Spot* a, Spot* b, void* context) {
    CGFloat xa = a.position.x;
    CGFloat xb = b.position.x;
    if (xa < xb)
        return NSOrderedAscending;
    return xa > xb ? NSOrderedDescending : NSOrderedSame;
}

...

spots = [spots sortedArrayUsingFunction:leftToRight context:NULL];

Now the interesting part: binary search using C++. We use the library function std::lower_bound from #include <algorithm>. It takes a starting iterator, an end iterator, the value to look for and a comparison function. It returns the first value for which the comparison function returns false. Start and end iterators can be simple C pointers into the array.

#include <algorithm>
...

bool cmpX(const CGPoint& a, const CGPoint& b) {
    return a.x < b.x;
}
...

CGFloat yMin = CGRectGetMinY(aRect);
CGFloat yMax = CGRectGetMaxY(aRect);

CGPoint* begin = (CGPoint*)[_spotsData bytes];
CGPoint* end = begin + _spotCount;

CGPoint leftMargin = aRect.origin;
CGPoint rightMargin;
rightMargin.x = CGRectGetMaxX(aRect);

CGPoint* left  = std::lower_bound(begin, end, leftMargin, cmpX);
CGPoint* right = std::lower_bound(left, end, rightMargin, cmpX);

NSUInteger count = 0;
for (CGPoint* i = left; i != right; ++i) {
    if (i->y > yMin && i->y < yMax)
        ++count;
}

Note, that the second binary search, the one that finds the right margin, only starts searching from the left margin, not the whole array. Another optimization was to remove the X-axis checks from the loop, since that’s already done by determining the margins.

With these optimizations, the code takes only about one millisecond to count the points in the rectangle. That’s two hundred times faster than the first version and fast enough for the intended use.

Results

Here’s the output of the example project, running on three different devices. If you want run the code on your own device, keep in mind that you have to change the Code Signing Identity in the target settings. If you don’t use a universal application identifier in your profile, you also have to change the Bundle Identifier in the Info.plist file from »com.savoysoftware.spotsDB« to whatever your identifier is.

iPhone 3G:

SpotsDB1 needed 3.2 seconds to count spots in 13 rects
that's 244.423 ms per rect
SpotsDB2 needed 3.0 seconds to count spots in 55 rects
that's 55.230 ms per rect
SpotsDB3 needed 3.0 seconds to count spots in 2988 rects
that's 1.004 ms per rect

Second generation iPod Touch:

SpotsDB1 needed 3.1 seconds to count spots in 16 rects
that's 194.756 ms per rect
SpotsDB2 needed 3.0 seconds to count spots in 65 rects
that's 46.450 ms per rect
SpotsDB3 needed 3.0 seconds to count spots in 3399 rects
that's 0.883 ms per rect

Simulator running on a Mac Pro:

SpotsDB1 needed 3.0 seconds to count spots in 687 rects
that's 4.372 ms per rect
SpotsDB2 needed 3.0 seconds to count spots in 2687 rects
that's 1.117 ms per rect
SpotsDB3 needed 3.0 seconds to count spots in 187276 rects
that's 0.016 ms per rect

Conclusion

When looking at the results it gets obvious that there’s a huge difference in performance between a desktop computer and the iPhone. Translating the numbers to a rule of thumb you could say: »What takes one second on a Mac takes one minute on the iPhone«. Or, what sounds even worse to me: »A frame rate of 60Hz on a Mac means one update per second on the iPhone«.

There’s obviously a big need for optimized code on the iPhone. In this article, I showed a couple of ways to reduce the overhead of Objective C and how to maximize performance using C++. Of course it’s not always so easy to get at the bottlenecks and simply switch some data structures to make the code fly. But when designing the architecture of data intensive applications, it’s absolutely worth looking at non-Cocoa ways to help coping with the restrictions of mobile devices.

Today, Spots has been released in the App Store. Spots is the first application for locating hotspots worldwide without requiring an internet connection and it is our first application in the App Store. Please check out the the video and screenshots on our product website or go to the App Store directly.

Merry Christmas!