2012-06-23 5 views
6

J'utilise NSFetchRequest très basique pour récupérer une entité MessageObject. Je n'ai que 2 000 objets de message, et je veux les récupérer tous. Cependant, pour une raison étrange, la requête d'extraction prend plus de 10 secondes!La récupération des données de base est extrêmement lente

NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init]; 
NSEntityDescription *entity = [NSEntityDescription entityForName:@"MessageObject" inManagedObjectContext:appDelegate.managedObjectContext]; 
[fetchRequest setEntity:entity]; 
NSSortDescriptor *sort= [[NSSortDescriptor alloc] initWithKey:@"createDate" ascending:NO selector:@selector(compare:)]; 
[fetchRequest setSortDescriptors:[NSArray arrayWithObject:sort]]; 
[fetchRequest setFetchBatchSize:5]; 

Et c'est tout, c'est ma demande d'extraction. Je n'utilise même pas de prédicat, et cela prend plus de 10 secondes. Je n'ai absolument aucune idée de ce qui pourrait en être la cause. Si quelqu'un a des idées ou des points de départ, s'il vous plaît partager.

J'ai également essayé d'activer la journalisation de débogage SQLite (-com.apple.CoreData.SQLDebug 1), mais je reçois juste des milliers de lignes de sortie à partir de cette simple extraction. Est-ce normal?

2012-06-22 19:39:59.171 myapp[81825:15e03] about to execute fetch 
2012-06-22 19:39:59.172 myapp[81825:15e03] CoreData: sql: SELECT 0, t0.Z_PK FROM ZMBNOTEOBJECT t0 ORDER BY t0.ZCREATEDATE DESC 
2012-06-22 19:39:59.178 myapp[81825:15e03] CoreData: annotation: sql connection fetch time: 0.0061s 
2012-06-22 19:39:59.179 myapp[81825:15e03] CoreData: annotation: total fetch execution time: 0.0067s for 2052 rows. 
2012-06-22 19:39:59.179 myapp[81825:15e03] CoreData: sql: SELECT 0, t0.Z_PK, t0.Z_OPT, t0.ZAUTHOREMAIL, t0.ZAUTHORNAME, t0.ZCREATEDATE, t0.ZISGLOBAL, t0.ZISLOCKED, t0.ZISNEW, t0.ZISPENDINGDELETE, t0.ZISPENDINGLIKE, t0.ZISPENDINGREAD, t0.ZISPENDINGSYNC, t0.ZLASTUPDATED, t0.ZLOCALLYMODIFIEDDATE, t0.ZMAINIDEA, t0.ZMETALASTUPDATED, t0.ZNOTEID, t0.ZNUMBEROFCHILDREN, t0.ZPARENTAUTHOREMAIL, t0.ZPARENTNOTEID, t0.ZROOTAUTHOREMAIL, t0.ZROOTNOTEID, t0.Z4PENDINGADDNOTES, t0.Z4PENDINGREMOVENOTES FROM ZMBNOTEOBJECT t0 WHERE t0.Z_PK IN (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?) ORDER BY t0.ZCREATEDATE DESC LIMIT 15 
2012-06-22 19:39:59.180 myapp[81825:15e03] CoreData: annotation: sql connection fetch time: 0.0008s 
2012-06-22 19:39:59.181 myapp[81825:15e03] CoreData: annotation: total fetch execution time: 0.0018s for 15 rows. 
2012-06-22 19:39:59.182 myapp[81825:15e03] CoreData: sql: SELECT 0, t0.Z_PK, t0.Z_OPT, t0.ZAUTHOREMAIL, t0.ZAUTHORNAME, t0.ZCREATEDATE, t0.ZISGLOBAL, t0.ZISLOCKED, t0.ZISNEW, t0.ZISPENDINGDELETE, t0.ZISPENDINGLIKE, t0.ZISPENDINGREAD, t0.ZISPENDINGSYNC, t0.ZLASTUPDATED, t0.ZLOCALLYMODIFIEDDATE, t0.ZMAINIDEA, t0.ZMETALASTUPDATED, t0.ZNOTEID, t0.ZNUMBEROFCHILDREN, t0.ZPARENTAUTHOREMAIL, t0.ZPARENTNOTEID, t0.ZROOTAUTHOREMAIL, t0.ZROOTNOTEID, t0.Z4PENDINGADDNOTES, t0.Z4PENDINGREMOVENOTES FROM ZMBNOTEOBJECT t0 WHERE t0.Z_PK IN (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?) ORDER BY t0.ZCREATEDATE DESC LIMIT 15 
2012-06-22 19:39:59.186 myapp[81825:15e03] CoreData: annotation: sql connection fetch time: 0.0042s 
2012-06-22 19:39:59.187 myapp[81825:15e03] CoreData: annotation: total fetch execution time: 0.0049s for 15 rows. 
2012-06-22 19:39:59.187 myapp[81825:15e03] CoreData: sql: SELECT 0, t0.Z_PK, t0.Z_OPT, t0.ZAUTHOREMAIL, t0.ZAUTHORNAME, t0.ZCREATEDATE, t0.ZISGLOBAL, t0.ZISLOCKED, t0.ZISNEW, t0.ZISPENDINGDELETE, t0.ZISPENDINGLIKE, t0.ZISPENDINGREAD, t0.ZISPENDINGSYNC, t0.ZLASTUPDATED, t0.ZLOCALLYMODIFIEDDATE, t0.ZMAINIDEA, t0.ZMETALASTUPDATED, t0.ZNOTEID, t0.ZNUMBEROFCHILDREN, t0.ZPARENTAUTHOREMAIL, t0.ZPARENTNOTEID, t0.ZROOTAUTHOREMAIL, t0.ZROOTNOTEID, t0.Z4PENDINGADDNOTES, t0.Z4PENDINGREMOVENOTES FROM ZMBNOTEOBJECT t0 WHERE t0.Z_PK IN (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?) ORDER BY t0.ZCREATEDATE DESC LIMIT 15 
2012-06-22 19:39:59.188 myapp[81825:15e03] CoreData: annotation: sql connection fetch time: 0.0008s 
2012-06-22 19:39:59.189 myapp[81825:15e03] CoreData: annotation: total fetch execution time: 0.0014s for 15 rows. 
... (thousands of more lines similar to above) 

Je ne suis pas très familier avec la lecture, mais il semble qu'il va chercher 2052 lignes dans .0067 secondes. Alors pourquoi continue-t-il à faire plus de choses après ça? La requête ne devrait-elle pas finir si elle a fini d'aller chercher les lignes? Est-ce une faute sur les données ou quelque chose?

En outre, j'ai supprimé setFetchBatchSize - qui s'est débarrassé des milliers de lignes, mais la demande d'extraction prend encore beaucoup de temps. Ceci est la sortie je reçois:

2012-06-22 20:07:25.316 myapp[8927:707] about to execute fetch 
2012-06-22 20:07:25.322 myapp[8927:707] CoreData: sql: SELECT 0, t0.Z_PK, t0.Z_OPT, t0.ZAUTHOREMAIL, t0.ZAUTHORNAME, t0.ZCREATEDATE,t0.ZISLOCKED, t0.ZISNEW, t0.ZISPENDINGDELETE, t0.ZISPENDINGSYNC, t0.ZLASTUPDATED, t0.ZLOCALLYMODIFIEDDATE, t0.ZMAINIDEA, t0.ZMETALASTUPDATED, t0.ZNOTEID, t0.ZNUMBEROFCHILDREN, t0.ZPARENTAUTHOREMAIL, t0.ZPARENTNOTEID, t0.ZROOTAUTHOREMAIL, t0.ZROOTNOTEID, t0.Z4PENDINGADDNOTES, t0.Z4PENDINGREMOVENOTES FROM ZMBNOTEOBJECT t0 ORDER BY t0.ZCREATEDATE DESC 
2012-06-22 20:07:26.758 myapp[8927:707] CoreData: annotation: sql connection fetch time: 1.0891s 
2012-06-22 20:07:26.763 myapp[8927:707] CoreData: annotation: total fetch execution time: 1.4407s for 4000 rows. 
2012-06-22 20:07:35.967 myapp[8927:707] finished fetching 

Ce qui est étrange est que, à 20: 07: 26,763 il dit apparemment il a fallu 1.4407 secondes pour 4000 lignes, mais pas pendant 9 secondes puis-je obtenir la sortie en disant « fini aller chercher "(qui est une déclaration NSLog qui apparaît après [[self fetchedResultsController] performFetch:&error]) Qu'est-ce qui se passe avec ça?

Répondre

2

Supprimer setFetchBatchSize.

Si vous avez l'intention de tout charger en même temps, retirez-le.

De plus, si vous avez besoin de charger tous les attributs, ajouter:

fetchRequest.returnsObjectsAsFaults = NO; 

Il chargera toutes les entités et remplir les attributs.

Vous pouvez vouloir ne charger que certains attributs, donc l'utiliser pour sélectionner ce que vous avez besoin:

fetchRequest.propertiesToFetch = ... 

Et vous avez terminé.

+0

Eh bien, je ne veux pas vraiment aller chercher tout, je l'ai fait pour le plaisir de tester. En réalité, j'aurai un prédicat, mais juste pour le tester, je voulais voir combien de temps il faudrait pour récupérer toutes les entités sans prédicat (parce que le prédicat prenait aussi trop de temps). Mais après avoir enlevé setFetchBatchSize, je n'ai plus de milliers de lignes de logs SQL. Mais je veux garder le batchSize. – Snowman

+0

Si vous le gardez, alors les données de base devront résoudre des milliers de fautes, d'où les demandes que vous voyez. Cela prend énormément de temps. –

+0

Mais ne devrait-il pas seulement résoudre les défauts quand ils sont nécessaires? Ma table n'affiche que 4 cellules à la fois, alors pourquoi est-il en défaut dans des milliers d'objets immédiatement? – Snowman

Questions connexes