Using NSOperatonQueue to speed up long calculation - ios

Question

I'm looking for ways to speed up a lengthy calculation (with two nested for-loops), the results of which will be shown in a plot. I tried NSOperationQueue thinking that each of the inner for loops would run concurrently. But apparently that's not the case, at least in my implementation. If I remove the NSOperationQueue calls, I get my results in my plot, so I know the calculation is done properly.
Here's a code snippet:
NSInteger half_window, len;
len = [myArray length];
if (!len)
return;
NSOperationQueue *queue = [[NSOperationQueue alloc] init];
half_window = 0.5 * (self.slidingWindowSize - 1);
numberOfPoints = len - 2 * half_window;
double __block minY = 0;
double __block maxY = 0;
double __block sum, y;
xPoints = (double *) malloc (numberOfPoints * sizeof(double));
yPoints = (double *) malloc (numberOfPoints * sizeof(double));
for ( NSUInteger i = half_window; i < (len - half_window); i++ )
{
[queue addOperationWithBlock: ^{
sum = 0.0;
for ( NSInteger j = -half_window; j <= half_window; j++ )
{
MyObject *mo = [myArray objectAtIndex: (i+j)];
sum += mo.floatValue;
}
xPoints[i - half_window] = (double) i+1;
y = (double) (sum / self.slidingWindowSize);
yPoints[i - half_window] = y;
if (y > maxY)
maxY = y;
if (y < minY)
minY = y;
}];
[queue waitUntilAllOperationsAreFinished];
}
// update my core-plot
self.maximumValueForXAxis = len;
self.minimumValueForYAxis = floor(minY);
self.maximumValueForYAxis = ceil(maxY);
[self setUpPlotSpaceAndAxes];
[graph reloadData];
// cleanup
free(xPoints);
free(yPoints);
Is there a way to make this execute any faster?

Answer 1

You are waiting for all operations in the queue to finish after adding each item.
[queue waitUntilAllOperationsAreFinished];
}
// update my core-plot
self.maximumValueForXAxis = len;
should be
}
[queue waitUntilAllOperationsAreFinished];
// update my core-plot
self.maximumValueForXAxis = len;
You are also setting sum variable to 0.0 in each operation queue block.

Answer 2

This looks odd:
for ( NSUInteger j = -half_window; j <= half_window; j++ )
Assuming half_window is positive then you're setting an unsigned int to a negative number. I suspect that this will generate a huge unsigned int which will fail the condition which means this loop never gets calculated.
However, this isn't the cause of your slowness.

Answer 3

Revised answer
Below, in my original answer, I address two types of performance improvement, (1) designing responsive UI by moving complicated calculations in the background; and (2) making complicated calculations perform more quickly by making them multi-threaded (but which is a little complicated so be careful).
In retrospect, I now realize that you're doing a moving average, so your performance hit by doing nested for loops can be completely eliminated, cutting the Gordian knot. Using pseudo code, you can do something like the following, which updates the sum by removing the first point and adding the next point as you go along (where n represents how many points you're averaging in your moving average, e.g. a 30 point moving average from your large set, n is 30):
double sum = 0.0;
for (NSInteger i = 0; i < n; i++)
{
sum += originalDataPoints[i];
}
movingAverageResult[n - 1] = sum / n;
for (NSInteger i = n; i < totalNumberOfPointsInOriginalDataSet; i++)
{
sum = sum - originalDataPoints[i - n] + originalDataPoints[i];
movingAverageResult[i] = sum / n;
}
That makes this a linear complexity problem, which should be much faster. You definitely do not need to break this into multiple operations that you add to some queue to try to make the algorithm run multi-threaded (e.g. which is great because you therefore bypass the complications I warn you of in my point #2 below). You can, though, wrap this whole algorithm as a single operation that you add to a dispatch/operation queue so it runs asynchronous of your user interface (my point #1 below) if you want.
Original answer
It's not entirely clear from your question what the performance issue is. There are two classes of performance issues:
User interface responsiveness: If you're concerned about the responsiveness of the UI, you should definitely eliminate the waitUntilAllOperationsAreFinished because that is, at the end of the day, making the calculation synchronous with respect to your UI. If you're trying to address responsiveness in the user interface, you might (a) remove the operation block inside the for loop; but then (b) wrap these two nested for loops inside a single block that you would add to your background queue. Looking at this at a high level, the code would end up looking like:
[queue addOperationWithBlock:^{
// do all of your time consuming stuff here with
// your nested for loops, no operations dispatched
// inside the for loop
// when all done
[[NSOperationQueue mainQueue] addOperationWithBlock:^{
// now update your UI
}];
}];
Note, do not have any waitUntilAllOperationsAreFinished call here. The goal in responsive user interfaces is to have it run asynchronously, and using waitUntil... method effectively makes it synchronous, the enemy of a responsive UI.
Or, you can use the GCD equivalent:
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
// do all of your time consuming stuff here
// when all done
dispatch_async(dispatch_get_main_queue(), ^{
// now update your UI
});
});
Again, we're calling dispatch_async (which is equivalent to making sure you don't call waitUntilAllOperationsAreFinished) to make sure we dispatch this code to the background, but then immediately return so our UI remains responsive.
When you do this, the method that does this will return almost instantaneously, keeping the UI from stuttering/freezing during this operation. And when this operation is done, it will update the UI accordingly.
Note, this presumes that you're doing this all in a single operation, not submitting a bunch of separate background operations. You're just going to submit this single operation to the background, it's going to do its complicated calculations, and when it's done, it will update your user interface. In the mean time your user interface can continue to be responsive (let the user do other stuff, or if that doesn't make sense, show the user some UIActivityIndicatorView, a spinner, so they know the app is doing something special for them and that it will be right back).
The take-home message, though, is that anything that will freeze (even temporarily) a UI is a not a great design. And be forewarned that, and if your existing process takes long enough, the watchdog process may even kill your app. Apple's counsel is that, at the very least, if it takes more than a few hundred milliseconds, you should be doing it asynchronously. And if the UI is trying to do anything else at the same time (e.g. some animation, some scrolling view, etc.), even a few hundred milliseconds is far too long.
Optimizing performance by making the calculation, itself, multi-threaded: If you're trying to tackle the more fundamental performance issue of this by making multi-threaded, far more care must be taken regarding the how you do this.
First, you probably want to restrict the number of concurrent operations you have to some reasonable number (you never want to risk using up all of the available threads). I'd suggest you set maxConcurrentOperationCount to some small, reasonable number (e.g. 4 or 6 or something like that). You'll have diminishing returns at that point anyway, because the device only has a limited number of cores available.
Second, and just as important, you should to pay special attention to the synchronizing of your updating of variables outside of the operation (like your minY, maxY, etc.). Let's say maxY is currently 100 and you have two concurrent operations, one which is trying to set it to 300 and another that is trying to set it to 200. But if they both confirm that they're greater than the current value, 100, and proceed to set their values, if the one that is setting it to 300 happens to win the race, the other operation can reset it back to 200, blowing away your 300 value.
When you want to write concurrent code with separate operations updating the same variables, you have to think very carefully about synchronization of these external variables. See the Synchronization section of the Threading Programming Guide for a discussion of a variety of different locking mechanism that address this problem. Or you can define another dedicate serial queue for synchronizing the values as discussed in Eliminating Lock-Based Code of the Concurrency Programming Guide.
Finally, when thinking about synchronization, you can always step back and ask yourself whether the cost of doing all of this synchronization of these variables is really necessary (because there is a performance hit when synchronizing, even if you don't have contention issues). For example, although it might seem counter-intuitive, it might be faster to not try to update to minY and maxY at all during these operations, eliminating the need for synchronization. You could forgo the calculation of those two variables for the range of y values as the calculations are being done, but just wait until all of the operations are done and then do one final iteration through the entire result set and calculate the min and max then. This is an approach that you can verify empirically, where you might want to try it both with locks (or other synchronization method) and then again, calculating the range of values as a single operation at the very end where locks wouldn't be necessary. Surprisingly, sometimes adding the extra loop at the end (and thereby eliminating the need to synchronize) can be faster.
The bottom line is that you can't generally just take a serial piece of code and make it concurrent, without special attention to both of these considerations, constraining how many threads you'll consume and if you're going to be updating the same variables from multiple operations, consider how you're going to synchronize the values. And even if you decide to tackle this second issue, the multi-threaded calculation itself, you should still think about the first issue, the responsive UI, and perhaps marry both methods.