On the Slowness of Core Data External Binary Storage
I recently closed out an issue surround the support for resetting persistent stores within the RKManagedObjectStore class. The crux of the issue was that during a store reset, we manually remove the SQLite files backing any SQLite persistent stores that have been added to the manager, but we did not take any steps to cleanup External Binary Storage support, so you would wind up leaving behind binary data on disk.
The fix is pretty simple: you calculate the name of the binary storage directory (it’s ’.<Persistent Store Name>_Support’) and remove the directory during a reset. Simple. But to be sure my implementation was correct, I knocked out some unit tests by adding an an external transformable attribute to the unit testing model and made sure they were green and pushed the work to Github. See https://github.com/RestKit/RestKit/commit/aecc1db3524079c1a72d2ddc2f63f98fa5c6d12a
Later today I noticed something – my unit tests were now taking 120 seconds to execute the ~600 test cases in RestKit. Just yesterday, I remember noting that the suite was taking about 20 seconds to run. I did a binary search back through history and found that just **adding** the External Storage attribute to the model, even though it was unused, was accounting for the entire slow down.
There appears to be some very real performance overhead associated with introducing external binary storage to your Core Data model. I would recommend benchmarking and evaluating other solutions before going down this road in a production application.