Rendimiento CoreData sobre el ahorro de contexto

Question

Terminé de convertir mi aplicación para usar la capa CoreData para un pequeño almacén de datos que quiero usar. Tengo algunas preocupaciones sobre el rendimiento y la mejor manera de usarlo. En particular: Tengo muchas ejecuciones donde leo atributos de disco dentro de archivos: cada atributo debe generar un nuevo objeto, a menos que ya exista un objeto de ese tipo y ese valor. Entonces, para cada archivo que leo, I: ejecuto una búsqueda para verificar si ese objeto administrado ya existe; en caso afirmativo, termine; de ​​lo contrario, creo el objeto, asigno valor y guardo el contexto.

Actualmente, guardo el contexto una vez por cada vez que creo un nuevo objeto, por lo que ocurre más o menos diez veces (para los diez atributos) para cada archivo leído (que puede ser cientos). Sería mejor reducir los puntos de ahorro de contexto, tal vez una vez para el archivo en lugar de una vez para el atributo? No conozco la sobrecarga de esta operación, así que no sé si está bien hacerlo tantas veces, o cómo averiguar el tiempo dedicado a esto (¿tal vez con los instrumentos? No sé cómo).

Answer 1

No es necesario guardar después de configurar cada atributo.

Normalmente, solo guarda un objeto gestionado cuando el código está terminado, ya que al guardar se restablece el deshacer. En la configuración que describes, puedes generar cientos de objetos administrados de forma segura antes de guardarlos en la tienda permanente. Puede tener un gran número (miles) de objetos livianos (atributos de texto) en la memoria sin ejercer ninguna presión sobre el iPhone.

El único problema en el iPhone es que nunca se sabe cuándo se suspenderá o cerrará la aplicación. Esto hace que los guardados sean más comunes que en otras plataformas. Sin embargo, no en la medida en que ahora lo use.

Core Data Performance section de la guía puede ayudarle a planificar. Instruments le permite ver los detalles del rendimiento de Core Data.

Sin embargo, no haría nada hasta que haya probado la aplicación con una gran cantidad de datos y la haya encontrado lenta. La optimización prematura es la fuente de todo mal. No pierdas el tiempo tratando de prevenir un problema que quizás no tengas.

Answer 2

Para evitar un problema de "parada repentina aplicación" puede implementar algo así como que el método:

- (void)saveContext { 

NSError *error = nil; 
NSManagedObjectContext *managedObjectContext = self.managedObjectContext; 


if (managedObjectContext != nil) { 
    if ([managedObjectContext hasChanges] && ![managedObjectContext save:&error]) { 
     /* 
     Replace this implementation with code to handle the error appropriately. 

     abort() causes the application to generate a crash log and terminate. You should not use this function in a shipping application, although it may be useful during development. If it is not possible to recover from the error, display an alert panel that instructs the user to quit the application by pressing the Home button. 
     */ 
     LogError(@"Unresolved error %@, %@", error, [error userInfo]); 
      // abort(); 
    } 
} 

}

y utilizarlo dentro de dos métodos de delegado de la aplicación:

- (void)applicationWillTerminate:(UIApplication *)application; 

y

- (void)applicationDidEnterBackground:(UIApplication *)application; 

Pensé que podría no ser la solución al 100%, pero en la mayoría de los casos hará el trabajo ...