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.
Struct
s 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.
Struct
s with two int
or four double
s 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 struct
s as properties of an object: you can't do
object.frame.origin.x=10;
If you start making your own struct
s, you need to remember which is which. That's again a hassle. I think the reason why they (NSRect
etc.) are struct
s 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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With