I'm working at the audio buffer level, mixing audio signals created by a colleciton of objects. Since I'm looping through these objects at 44.1khz, efficiency is crucial. Is there any difference in the efficiency of iterating over an NSArray vs a C array of pointers? How about NSMutableArray?
+4
A:
Is there any difference in the efficiency of iterating over an NSArray vs a C array of pointers?
Yes. Iterating directly over a C array will be faster.
Most apps don't need to worry about this and should look elsewhere for performance gains. But if, in your app, this function runs 44,100 times per second, you probably should micro-optimize it (after, of course, making sure that it does as little as possible—that is, only the things you absolutely need to do 44,100 times per second).
How about NSMutableArray?
Vs. an NSArray? No difference that you can rely on or should care about.
Peter Hosey
2010-03-13 23:31:13
Of course, if he is doing an audio app and not vectorizing his code to avoid iterating as much as possible, there are likely to be other performance issues....
bbum
2010-03-14 01:16:14
http://www.savoysoftware.com/blog/my-iphone-is-not-a-mac-pro/ has some details on optimizing Cocoa using C/C++ … in his case switching away from NSArray/CGRectContainsPoint() was a ~4x boost, but changing the algorithm was a ~200x gain.
Vincent Gable
2010-03-14 10:53:58
Interesting. Thanks folks.
morgancodes
2010-03-15 18:22:06
A:
The NSFastEnumeration protocol defines -countByEnumeratingWithState:objects:count: which uses a C array for iteration of NSArrays, NSMutableArrays, and any other collection objects that conform to it, avoiding a call to -objectAtIndex: each iteration. Use performance analysis to determine which is the fast enough solution.
Preston
2010-03-14 05:43:12
Actually, it doesn't. Fast enumeration is a way of letting the collection class manage iteration entirely internally, but there is nothing about it remotely akin to C arrays.
bbum
2010-03-14 06:34:30
The protocol declares countByEnumeratingWithState:objects:count: with the description:"Returns by reference a C array of objects over which the sender should iterate, and as the return value the number of objects in the array."
Preston
2010-03-14 06:43:27
Right-- but that is neither anything at all like enumerating a straight C array, nor does that mean that the *internal structure* of the collection class is a C array. You are still going to pay the cost of copying references and managing the fast enumeration metadata. It will still be slower than a regular old C array -- not as much as -objectEnumerator, but still significant, especially for audio processing.
bbum
2010-03-14 06:50:48
I wasn't referring to the internal structures of the collection classes, just that for...in iterates over a C array.
Preston
2010-03-14 07:23:24
`for(... in ...)` does **not** iterate over a C array, but over a series of C arrays. There is no *single* C array created for the enumeration and the performance profile is *entirely different* from that of iterating over a single contiguous C array.
bbum
2010-03-14 19:00:07
I'm well aware of fast enumeration's implementation. I didn't get into performance profiles because I assumed that the original poster would be doing that to determine the best solution. My reason for mentioning fast enumeration and C arrays in the first place was just to make the point that it won't be calling -objectAtIndex every iteration because it uses a C array instead.
Preston
2010-03-20 16:33:10