prestazioni CoreData sul contesto risparmio

Question

ho finito di convertire la mia app di utilizzare il livello di CoreData per una piccola datawarehouse voglio usare. Ho alcune preoccupazioni riguardo alle prestazioni e al modo migliore di utilizzarle. In particolare: Ho un sacco di piste dove ho letto dagli attributi del disco all'interno dei file: ogni attributo dovrebbe generare un nuovo oggetto, a meno che un oggetto di quel tipo e che il valore esiste già. Quindi, per ogni file che ho letto, I: eseguire un recupero per verificare se quell'oggetto gestito esiste già; se sì, altrimenti creo l'oggetto, assegna valore e salva contesto.

Attualmente, risparmio il contesto una volta per ogni volta che creo un nuovo oggetto, così accade più o meno dieci volte (per i dieci attributi) per ogni file letto (che può essere centinaia). Sarebbe meglio ridurre i punti di salvataggio del contesto, forse una volta per il file anziché una volta per l'attributo? Non conosco l'overhead di questa operazione in modo da non so se è ok per farlo così spesso, o come trovare il tempo speso su questo (magari con gli strumenti? Non so davvero come).

Answer 1

Non c'è alcuna necessità di salvare dopo aver impostato ogni attributo.

Normalmente, si salva un oggetto gestito solo quando il codice viene eseguito con esso mentre il salvataggio reimposta l'annullamento. Nel set up che descrivi, potresti tranquillamente generare centinaia di oggetti gestiti prima di salvarli in un archivio permanente. Si può avere un gran numero (migliaia) di leggero (attributi di testo) oggetti in memoria senza mettere alcun sforzo su iPhone.

L'unico problema su iPhone è che non si sa mai quando l'app verrà sospesa o arrestata. Questo rende i salvataggi più comuni rispetto ad altre piattaforme. Tuttavia, non nella misura in cui ora usi.

Core Data Performance section della guida potrebbe aiutarti a pianificare. Instruments ti permette di vedere i dettagli delle prestazioni dei Core Data.

Tuttavia, non farei nulla finché non avrò testato l'app con una grande quantità di dati e l'ho trovata lenta. L'ottimizzazione prematura è la fonte di ogni male. Non perdere tempo a cercare di prevenire un problema che potresti non avere.

Answer 2

Per evitare un problema "arresto improvviso applicazione" è possibile implementare qualcosa di simile metodo:

- (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(); 
    } 
} 

}

e utilizzarlo all'interno di due metodi di vostra applicazione delegato:

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

e

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

Pensato che potrebbe non essere la soluzione al 100%, ma nella maggior parte dei casi farà il lavoro ...