Question

If I make my object a subclass of UIViewController, does it use substantially more memory than if it is a subclass of NSObject? A ballpark figure for how much more overhead is used by subclassing a complex class vs a simple one would be great. edit: or a way to figure out the difference myself.

Was it helpful?

Solution

You can imagine that an objective-c object is just a C structure that looks like this:

typedef struct {
    Class isa;
} NSObject;

An instance of that structure would take 4 bytes on a 32-bit system. Since it's composed of a single pointer - Class is similar to id.

A subclass of NSObject, MySubclass with one 'char' instance variable would look like this:

typedef struct {
    Class isa;
    char singleInstanceVariable.
 } MySubclass;

A subclass simply has all of the instance variables of its super class at the beginning, plus its own at the end. You can see this in the debugger by typing 'p *object' in the console.

MySubclass's size would be 5 bytes on a 32-bit system. One pointer, plus one char. So, an object's size is the size of all of it's instance variables added together. One important thing to know is that an object's size is only related to its instance variables. It isn't impacted by the number of methods it has. Those methods don't cost any extra memory as more instances are instantiated. Methods have a fixed initial cost.

Another thing to consider is that objects usually have pointers to other objects as instance variables. For example, let's say every UIView has an NSMutableArray to reference its subviews. That array might be 12 bytes when empty. So an empty UIView would be the size of all of the variables in a UIView, which would include 4 bytes for the pointer to an array, plus you might also account for the 12 additional bytes used by the actual array instance. That's all just accounting though, the array and the view are two distinct objects, but the view isn't really usable without the array.

Lastly, most allocations are rounded up to some quantum in order to make the malloc implementation faster and to satisfy some constraints of the architecture of the machine so that pointers are properly aligned. Also an object's instance variables might have empty padding in between them similar to structure padding

OTHER TIPS

That depends on the number and nature of the superclass's instance variables. NSObject has one ivar, the isa pointer. UIViewController has about 30 ivars, most of them pointers (you can look the list up in UIViewController.h).

So any subclass of UIViewController will take up as much memory as is needed to store all those ivars and all ivars of its superclasses (UIResponder (no ivars) and NSObject (one ivar)).

This calculation does not take into account the actual memory that is used by the objects these instance variables reference when initialized, of course. For example, a fully initialized view controller may hold on to a view object that takes up a considerable amount of memory.

Try class_getInstanceSize([MyClass class]);. Roughly speaking, the memory usage of an instance will be this value rounded up to a multiple of sixteen bytes. Of course, this doesn’t include overhead of any associated objects (see objc_setAssociatedObject) or allocations the class makes.

In short, yes, but probably not enough that you need to worry about it unless you're planning on instantiating tens thousands of them.

The object will allocate memory for each of its ivars and its methods. The amount of memory needed depends on the C types... they all vary according to the datatype what's being stored.

The amount of memory used depends on how the object is instantiated, presented on screen, and interacted with. For example, a subclass of NSObject will not have any interaction with the user's touches.

You can always attach you application with the Instruments Allocations performance tool to compare the difference.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top