User Profile

nocsi - Thank you for taking a look ! 🙂The issue is indeed blocked UI during transactions. The setup is exactly as was mentioned here:perform the writes onto a child private queue context as you've mentioned - then merge it against the main context.However, when i am saving big amounts of data into core data UI freeze. As far as i understand NSFetchedResultsControllerDelegate will calculate all the required changes in indexPaths on the main thread. And since our UI is tight to the linked FetchResultsController which is with mainQueueConcurrencyType, my UI freeze. The duration of time in which the UI freeze is getting bigger if the amount of objects we are saving into core data is getting bigger.So i have used privateQueueConcurrencyType instead. And now everything seem to work. No freeze. I do need to dispatch all of my UI transactions into the main thread. But that seem like a good compromise considering previous freeze.As far as i understand core data is not optimized for storing really big amounts of data. Using the setup mentioned above and measure the amount of time taken to add a constant amount of 2000 random objects over and over again into the data base, i get a growing delay:delta time 0.3195030689239502 (empty data base)delta time 1.8090097904205322delta time 3.1822659969329834delta time 4.478667736053467delta time 5.796695947647095delta time 7.051335096359253delta time 8.188868999481201Looks more or less a linear growing delay with respect to the data base size.So my question is if we can use a privateQueueConcurrencyType for the collection view data source ? Since when i am using this setup i can at least avoid all UI freezing issues.

The question is whether for a tableView or collectionView, we have to use NSMainQueueConcurrencyType ? Since as mentioned here, https://forums.developer.apple.com/message/393419#393419Using NSMainQueueConcurrencyType blocks UI when we are trying to save big amounts of data into the core data