Closed zarv1k closed 8 years ago
Hi, I did some profiling with my test project loading 62 700 rows.
https://github.com/3lvis/SyncPerformance
parentContext
/**
The context for the main queue. Please do not use this to mutate data, use `performInNewBackgroundContext`
instead.
*/
public var mainContext: NSManagedObjectContext {
get {
if _mainContext == nil {
let context = NSManagedObjectContext(concurrencyType: .MainQueueConcurrencyType)
context.undoManager = nil
context.mergePolicy = NSMergeByPropertyStoreTrumpMergePolicy
context.persistentStoreCoordinator = self.persistentStoreCoordinator
NSNotificationCenter.defaultCenter().addObserver(self, selector: #selector(DATAStack.mainContextDidSave(_:)), name: NSManagedObjectContextDidSaveNotification, object: context)
_mainContext = context
}
return _mainContext!
}
}
@zarv1k could you verify if by making this change locally things actually improve on your side?
@3lvis I was made the exactly same changes before I had created this ticket. But I was not sure that such changes should be applied, because many other core data wrapper libraries are set up the main context in stack using parent/child pattern (open issue in MagicalRecord for example). However I just checked again and confirm that this changes improve memory usage and fetchBatchSize became work as expected.
Cool! I'm glad this is fixed :)
I use DATASource for showing large (~50000 rows) data set and using DATAStack.mainContext in NSFRC. When I set request.fetchBatchSize for optimizing memory usage purposes it is ignored somehow. And all 50000 rows loads into memory.
I research for the issue a little bit and found that there is an issue in Core Data when stack configured with usage of nested contexts. - http://openradar.appspot.com/11235622. Also here is what I found on StackOverflow
May be some workaround can be implemented in DATAStack for partially resolve the described issue. For example, DATAStack could provide so called newMainContext() method that should return context that have NSMainQueueConcurencyType and directly linked to Persistent Store Coordinator. Another possible solution (not sure about that): try to use background context in NSFRC that newBackgroundContext() method can return. But in this case this context should be notified about changes in persistent store that have been done in another background context and merge them for update table in UI.
Have you any thoughts about that? Thank you