Question

I'm using Coredata for my iOS application. It has about 20 tables and my application uses may images(Image Editting Application) in database. so database data is so huge and heavy.

One day i added several columns in one table. It's just String columns. Of course I know how to migrate and implement it, so i added new .xcdatamodel and change current. When i test in my device, i don't get any errors and clashes. So i released it to iOS developer center and it can be announced. At last, Many users start to update my app.

But some users said "Never finished update." "Update has needed 50 minutes." and so on...
Update means migration. I confirmed it by progress user reported. I can't believe Migration needs 50 minutes! But maybe it's true. Because when i test to use 50 image and save to CoreData, my devices took about 1 min. i think our customer uses 300 ~ 500 images and users other datas. In case of iPhone4 or iPhone4S, migration needs much time...

So i want to know how to speed up CoreData migration for these users.
Now i'm using automatic migrate, otherwise i can choose manual migration.
I found out some tips and told with engineers, and gathered it, i inferred manual migration is slower than automatic migration.
And i'm finding other solution in parallel. It's exporting coredata to PC. And PC migrates instead of iPhone. And iPhone imports migrated data. Does anyone know this way is possible?

Finally, I put my migration code. It's really simple.

@try {
    // init application (Before application:didFinishLaunchingWithOptions:)
LOG(@"start migration");

    NSPersistentStoreCoordinator *migPersistent;

    NSURL *storeURL = [[self applicationDocumentsDirectory] URLByAppendingPathComponent:[[self class] sqliteFileInDocumentsUrlString]];
    NSDictionary *options = [NSDictionary dictionaryWithObjectsAndKeys:
                             [NSNumber numberWithBool:YES], NSMigratePersistentStoresAutomaticallyOption,
                             [NSNumber numberWithBool:YES], NSInferMappingModelAutomaticallyOption,nil];
    NSError *error = nil;
    migPersistent = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel:[self managedObjectModel]];
    if (![migPersistent addPersistentStoreWithType:NSSQLiteStoreType
                                     configuration:nil
                                               URL:storeURL
                                           options:options
                                             error:&error]) {

        NSLog(@"Unresolved error %@, %@", error, [error userInfo]);
        [migPersistent release];
        return NO;
    }

    [migPersistent release];
    LOG(@"finish migration");
}
@catch (NSException *exception) {
    .....
}
@finally {
    // Do Nothing
}

In addtion, this code is runnning on MainThread.
like
ViewDidAppear(LoadingWindow) -> performSelector:withObject:afterDelay -> migration.


Thank you for watching this issue and sorry my cheep english..



Editted 2014.02.25 21:11

I got trace file and uploaded following URL.
https://www.dropbox.com/sh/dmlf4j4z3vkj3p0/DrDBL_guYy

[Test flow] (Device: iPodtouch 5th Gen iOS 7.0.6)
1. Inserted 195KB(Width:960,Height:1280) x 1000 images in previous version.
2. Install current version and run migration. It finished about 11min.

So why user gets 50min???


Editted 2014.02.26 8:59

Sorry, the above URL is Wrong. Please check this URL.
https://www.dropbox.com/s/8xaxwyfex7gyjdt/traceFolder.zip


Editted 2014.02.26 10:43

What is going on in -[PapeDataManager migrate]? Add the code if you can

It's Above code. this method got 184977x.

[migPersistent addPersistentStoreWithType:NSSQLiteStoreType configuration:nil URL:storeURL
                                           options:options error:&error]


What is going on in -[PapeDataManager repairImageNamePath]?

this method got 160775x.
[self.managedObjectContext save:&error]

self.managedObjectContext is NSManagedObjectContext.
save seems to be heavy process. Because It's after migrate.

And now, i have some questions.

(1) Running time summary of MainThread is about 6 min, however Process total time is 11 min on TimeProfiler. Why does this difference happen?

(2) When i push home button while migrating, migrate process will be dead? I'm just checking it. but if you know about this. please tell me that.


Editted 2014.02.26 12:09

About (2). I've tested with 50 images migrate.
BackGround Task has suspended when i push home button and 30sec later.

So like this flow
Application lunch -> Loading Start -> migrate -> (push HomeButton and send app to background) -> migrate finished -> BackGround Process Suspended -> (push App icon and send app to foreground) -> save -> Loading Finish

I don't know why Loading process will not continue when app in Background. Maybe the cause of our user get angry about long loading time is this.

Was it helpful?

Solution

Even with images in the persistent store that seems to be taking much longer than normal for an automatic/lightweight migration.

Assuming that you have now built up a test case with 500 images in it to track this down; the next step is to run instruments against the application while this migration is occurring and see where the time is being spent. If the time is truly in Core Data (and not some UI event going on) then please edit your post with the trace from Instruments.

It is quite possible that your application is trying to do something with the data immediately after the migration that is consuming the time. Difficult to tell without an instruments trace.

Update (From Trace)

What is going on in -[PapeDataManager migrate]? Add the code if you can

What is going on in -[PapeDataManager repairImageNamePath]?

The -repairImageNamePath is taking the most time and if you can solve that you will see a significant boost in performance.

Update 2

Turning on SQLite debug will let you see what is going on during all of that time. If it really is a ton of sql calls because of the blobs in your store then you will need to refactor your store, probably do a manual migration (not heavy, but export from Core Data and rebuild the file) to fix this.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top