I am calling refreshObject:mergeChanges:NO
on my objects to turn them into faults, after I call save on the Managed Object Context. However, this is creating a spike in memory usage.
I'm trying to turn the objects into faults, in order to break the reference cycles so that memory can be freed up.
Without calling refreshObject
my application is able to run for 30-40 mins before it is killed for consuming too much ram. However, if I call it after each context save, then it lasts barely a few minutes.
This is my Core Data stack:
# Persistent Store Coordinator <--+-- privateWriterContext (NSPrivateQueueConcurrencyType)
# |
# +----- defaultManagedObjectContext (NSMainQueueConcurrencyType) # for the main thread
# |
# +----- backgroundManagedObjectContext (NSPrivateQueueConcurrencyType) # for bg tasks
This is the code I am using to persist and then refreshObject
if privateWriterContext.MR_saveToPersistentStoreAndWaitWithError(error)
privateWriterContext.performBlockAndWait(
lambda {
privateWriterContext.registeredObjects.each do |object|
privateWriterContext.refreshObject(object, mergeChanges: false)
end
}.weak!
)
else
# handle error
end
I have read through other Stackoverflow questions where other people appear to have implemented refreshObject
successfully:
- Core Data - break retain cycle of the parent context
- Core Data memory usage while importing large dataset
And this is the relevant snippet of Apple's Object Lifetime Management documentation:
When you have relationships between managed objects, each object maintains a strong reference to the object or objects to which it is related. This can cause strong reference cycles. To ensure that reference cycles are broken, when you're finished with an object you can use the managed object context method refreshObject:mergeChanges: to turn it into a fault.