I'm looking for an easier way to manipulate audio buffers on the iPhone. Mainly I'm trying to avoid pointer issues and array count issues with C, but don't want to be slowed down by number objects like NSNumber or NSInteger which I would have to use with NSArray.
I've come across CFArray which seems like it might be a nice middle ground. Am I correct in this assumption? Or am I missing something?
Not really. CFArray is basically the same as NSArray, you can even cast between the two, this is called toll-free bridging.
CFArray (and its mutable counterpart) does allow you to specify your own callback functions for retaining and releasing the objects (pointers) in your array, which would allow you to store arbitrary pointers (not just NSObjects) in the array and implement your own memory management scheme, but I doubt that this would result in any real performance gains. For your use case, C arrays are probably the way to go.
If performance and memory size are of any concern, which they likely will be for real-time audio processing, stick to plain C arrays, and learn how to code array passing and access correctly.
You need to handle audio in C arrays anyway, as the iOS Audio Queue and Audio Unit APIs pass audio data using C arrays.
If you don't like C-style and want to use some need object oriented class-style I would really recommend to use C++, eg. std::vector or similar.
Do not use Objective-C for audio it's not made for signal processing! Obj-C is great for dealing with UI's and connecting objects within a signaling system. Any kind of 'real' computation should always be done in C or flat C++.
Related
After not programming for a long, long time (20+ years) I'm trying to get back into it. My first real attempt is a Scrabble/Words With Friends solver/cheater (pick your definition). I've built a pretty good engine, but it's solves the problems through brute force instead of efficiency or elegance. After much research, it's pretty clear that the best answer to this problem is a DAWG or CDWAG. I've found a few C implementations our there and have been able to leverage them (search times have gone from 1.5s to .005s for the same data sets).
However, I'm trying to figure out how to do this in pure Objective-C. At that, I'm also trying to make it ARC compliant. And efficient enough for an iPhone. I've looked quite a bit and found several data structure libraries (i.e. CHDataStructures ) out there, but they are mostly C/Objective-C hybrids or they are not ARC compliant. They rely very heavily on structs and embed objects inside of the structs. ARC doesn't really care for that.
So - my question is (sorry and I understand if this was tl;dr and if it seems totally a newb question - just can't get my head around this object stuff yet) how do you program classical data structures (trees, etc) from scratch in Objective-C? I don't want to rely on a NS[Mutable]{Array,Set,etc}. Does anyone have a simple/basic implementation of a tree or anything like that that I can crib from while I go create my DAWG?
Why shoot yourself in the foot before you even started walking?
You say you're
trying to figure out how do this in pure Objective-C
yet you
don't want to rely on a NS[Mutable]{Array,Set,etc}
Also, do you want to use ARC, or do you not want to use ARC? If you stick with Objective-C then go with ARC, if you don't want to use the Foundation collections, then you're probably better off without ARC.
My suggestion: do use NS[Mutable]{Array,Set,etc} and get your basic algorithm working with ARC. That should be your first and only goal, everything else is premature optimization. Especially if your goal is to "get back into programming" rather than writing the fastest possible Scrabble analyzer & solver. If you later find out you need to optimize, you have some working code that you can analyze for bottlenecks, and if need be, you can then still replace the Foundation collections.
As for the other libraries not being ARC compatible: you can pretty easily make them compatible if you follow some rules set by ARC. Whether that's worthwhile depends a lot on the size of the 3rd party codebase.
In particular, casting from void* to id and vice versa requires a bridged cast, so you would write:
void* pointer = (__bridge void*)myObjCObject;
Similarly, if you flag all pointers in C structs as __unsafe_unretained you should be able to use the C code as is. Even better yet: if the C code can be built as a static library, you can build it with ARC turned off and only need to fix some header files.
I realize that what counts as premature optimization has a subjective component, but this is an empirical or best-practices question.
When programming for iOS, should I prefer using struct and typedefs where the object has no "behavior" (methods, basically)? My feeling is that the struct syntax is a bit strange for a non-C person, but that it should be WAY lower profile. Then again, testing some cases with 50K NSObject instances, it doesn't seem bad (relative, I know). Should I "get used to it" (use structs where possible) or are NSObject instances okay, unless I have performance problems?
The typical case would be a class with two int member variables. I've read that using a struct to hold two NSString instances (or any NSObject subclass) is a bad idea.
Structs with NSObject instances in them are definitely a bad idea. You need -init and -dealloc to handle the retain count correctly. Writing retain and releases from the caller side is just insane. It will never pay off.
Structs with two int or four doubles are borderline cases. The Cocoa framework itself implements NSRect, NSPoint etc. as a struct. But that fact has confused lots and lots of newcomers. Honestly, even the distinction between primitive types and object types confused them. It becomes even confusing to me when you have structs as properties of an object: you can't do
object.frame.origin.x=10;
If you start making your own structs, you need to remember which is which. That's again a hassle. I think the reason why they (NSRect etc.) are structs are basically historical.
I would prefer to make everything objects. And use garbage collection if available.
And, don't ask people if something is worth optimizing or not. Measure it yourself by Instruments or whatever. Depending on the environment (ppc vs intel, OS X vs iOS, iPad vs iPhone) one way which was faster in a previous system might be slower in a new system.
An Objective C object has almost the same storage as a struct, except it is 4 bytes (8 bytes on 64 bit) bigger. That's it - just one pointer into a place where the runtime holds all the class information.
If you are that tight on memory, then lose the 4 bytes, but usually that's only for large numbers of objects: 50,000 Nsobjects vs structs is only 200k - you get a lot of stuff for that 200k. For a million objects, the cost will add up on an iPhone.
If you want to say transfer the items to openGL or need a c array for other purposes, then another option is to make ONE NSObject that has a malloc'ed pointer to all 50,000 integers. Then the objective c memory overhead is ~0, and you can encapsulate all the nasty malloc and free() stuff into the innards of one .m file.
Go with regular objects until you hit a measurable performance bottleneck. I’ve used high-level code even in tight game loops without problems – messaging, collection classes, autorelease pools, no problems.
I see no problem at all with using structs to hold small quantities of primitive (i.e. non object) types where there is no behaviour required. There are already several examples of this in the Cocoa frameworks (CGRect, CGSize, CGPoint, NSRange for example).
Do not use structs to hold Objective-C objects. It complicates the memory management in the reference counted environment and may break it altogether in the GC environment.
For me, I would prefer to use regular objects because you can easily do Object job with it like retain, release, autorelease. I only see quite few structs in Cocoa Framework like CGSize, CGRect and CGPoint. I think the reason is that they are being used a lot
I believe is a good idea to use structs specially if you are dealing with C-based frameworks , lets says OpenGL, CoreGraphics, CoreText specially stuff that will require a couple/triple of ints, doubles, chars, etc. (If they are already not implemented in some of Apple Frameworks: CGRect, CGPoint, CTRect, NSRange, etc...) C stuff plays and looks better with other C stuff.
I don't think I would write a subclass of NSObject containing a couple of ints. It's almost ridiculous. lol.
I'm getting up to speed with the new APIs introduced in OS 3.0, especially the cool new improvements to Core Animation (mostly on CALayer etc...). Now I'm trying to figure out how to use CAGradientLayer. It looks simple at first, but the NSArray it requires for the colors property must contain CGColorRef (according to the header file). I've tried casting to (id), but then the NSArray seems to contain NSCFType objects, which doesn't sound good.
Anybody figured how to use it or could point to some good code samples?
Thanks
Even though the NSCFType objects in the array "don't sound good", you are supposed to use CGColorRefs directly in the array. The same principle applies here as for the animation question I asked a while back. The examples I've seen for using this class all employ arrays of CGColorRefs.
I've got a pretty big A* pathfinding function that gets called frequently and has to be put in another thread because otherwise it will make my game stutter. I come from a Java background, and recently read a discussion about the speed of HashMap's (essentially the equivalent of NSDictionary) and the different implementations you can use. I'm curious how fast NSDictionary is and whether anyone has found it to be viable option for dealing with lots of immediate and temporary object allocations, or whether it's too slow for that.
Currently I'm using an NSMutableArray for the open and closed lists in the A* algorithm - I would be replacing the closed list with NSMutableDictionary due to the O(1) setObject:forKey and removeObject:forKey, and also creating an NSMutableDictionary that "mirrors" the open list. The pathing data is stored in a big NSMutableArray - I would leave this as-is because index access is fast enough (of course).
So my question is... would this be a noticeable speed improvement or should I roll my own lists and/or maps? I'm just not sure what NSDictionary does and I'd like to know.
If you're wondering how to optimize A*, I'd first ask you if you're using platform-independent extensions, like Iterative Deepening A* (aka IDA*), what kind of a heuristic you're using, and if you're using caching (transposition tables, pattern databases). The questions you're asking are too close to the metal for the moment, because you're optimizing parts of the system which are likely not holding you back.
Have a look at these course slides (especially lecture 10 and lecture 11)
Absolutely it makes a difference - I recently changed a naive implementation of A* using NSArray (is something in the list? iterate to find out...) for the lists and adjacents for NSDictionary (in the list? objectForKey!) and increased performance from not acceptable to acceptable with not too much work.
I feel that when I use NSArray, I might constraint myself some time in future. Are there any good reasons to prefer this "primitive" one instead of the "complex" one, which is mutable?
Using a non-mutable structure in your code is not much of a constraint - if it turns out that you need to modify it later on you can change to use a mutable one. It can be more of a constraint if you have it in an external interface mind you. The main advantages of non-mutable is that you gain thread safety and it is more easy to conceptualize the code - there is less to concern you if mutability is taken out of the equation. This is why we have const constraints and so on - if you don't have to modify the data it is better to say so up front.
One reason is the YAGNI principle. If you don't need a mutable array, don't use it. So your code will be easier to understand, test and maintain.
Remember that code is not only processed by a compiler but also read by coders or testers. Using NSMutableArray instead of NSArray has a meaning for them. It may be counterproductive to give them false information about your intentions.
In addition to the answers from Mssrs INFORMATION and mouviciel NSArray is faster than NSMutableArray. This is true for all the stati/mutable collections.