Using Structs in Objective-C (for iOS): Premature Optimization?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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

Answer 4

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.

Answer 5

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 hustle. 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.

Answer 6

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.