Save objects with many redundant information (with core data)

Question

I am designing an app in Objective-C that uses a core data structure.

I have the following structure :

@interface classA : NSManagedObject
@property(nonatomic, strong) someType1 * property1;
..
@property(nonatomic, strong) someTypeN * propertyN;
@property(nonatomic, strong) NSSet * children;
@end

and

@interface classB : classA
@property (nonatomic, strong) classA * parent;
@end

I have the following features :

1) Each object of classA will have many children in classB. (Objects in classB don't have children themselves).

2) Moreover, most objects of classB will share many properties in common with they parent (for instance, you can think that in most cases, only property1 will differ between an object of classB and the same property in its parent in classA, so for x in classB x.property2 = x.parent.property2 and so on).

3) I will only query the database through requests on object of type classA.

I am looking for a way to reduce the disk memory usage of my app by storing only the necessary properties of objects of type classB. For instance, I could keep properties of an object of classB set to nil unless it differs from the one of its parent, defining the getter of classB as :

- (sometypeX*) getPropertyX {
    if (propertyX) return propertyX;
    return parent.propertyX;
}

My questions are : 1) Am I really going to gain disk memory by filling my database with nil values instead of actual values 2) Are there drawbacks to such a construction 3) Are there better ways / design patterns to deal with this issue ?

Thanks in advance for any help.

Answer 1

Core Data is highly optimized. It already does what you're trying to implement using faulting . From Faulting and Uniquing in the docs:

Because a fault is not realized, a managed object fault consumes less memory, and managed objects related to a fault are not required to be represented in memory at all.

To answer your questions…

1) Am I really going to gain memory by filling my database with nil values instead of actual values

If you gain any memory with this approach, it's probably insignificant.

2) Are there drawbacks to such a construction

It adds lots of complexity to your code base without much justification. It makes your code harder to read, understand, and maintain.

3) Are there better ways / design patterns to deal with this issue

Just use Core Data in a way that's easy to understand, and let it handle the optimization unless you have a clear, measurable need to optimize further.

Answer 2

I have made some testing following the question I had asked.

I tested the following setting : I have a classA with 11 NSString properties and children in classB. classB is a subclass of classA with the same properties and a parent property.

I created randomly between 100 and 1000 instances of classA, each of which having between 10 and 1000 children in classB. For the objects of classA, I set each string property to be a random 10 characters string.

I tested two procedures : - either the fields of the children of an objectA is set to nil - or it is set to its parent property.

And I monitored the sizes of my database files.

Unfortunately I was not able to extract a linear law from the rate of growth of the files (while this works with only one class, I couldn't figure it out with this more complicated parent/children structure). Moreover I couldn't quite understand the repartition of the sizes between the file ending with .sqlite and the one ending with .sqlite-wal.

However in all the regimes tested (where the total db size is between 1 Mb and 100 Mb) I found that I gained around a factor of 3 when using the first procedure compared to the second.

So for this regime of use not setting some properties seem to lead to a negligible gain in db size.

Please tell me if you want me to elaborate more on this answer.