• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Core Data Fetch request very poor performance ??!
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Core Data Fetch request very poor performance ??!


  • Subject: Re: Core Data Fetch request very poor performance ??!
  • From: Chris Hanson <email@hidden>
  • Date: Mon, 28 Nov 2005 23:56:07 -0800

On Nov 28, 2005, at 11:22 PM, Aurélien Hugelé wrote:

Now using core data in SQL format, it is even worse, i mean REALLY worse because it is extremly slow, not to save, but to use to retrieve my objects!

What version of Mac OS X are you using?

Only 2 fetches requests are executed, and they basically ask for all stored emails.

The code of -[GCMKEmailManager storeAllObjectsOfMailBoxAtPath:] is like this :

(Code to fetch all email instances into allEmails elided.)

NSDictionary* uniqueIdsToEmails = [NSDictionary dictionaryWithObjects:allEmails forKeys:[allEmails valueForKey:@"uniqueId"]]; // cache the fetched objects

Rather than fetching all of your objects, and then putting them all in a cache, and keeping them all in memory, why not just fetch them only when needed? (Preferably via relationships, but fetch requests should work just as well.)


the email entity is very simple : it only has attributes (no relationship at all!) (about 28 attributes, of "native" types : string, number, bool)

You might also want to consider refactoring your managed object model to use more entities with fewer attributes per entity and relationships between them. Usually a data model with few entities and many attributes is well worth refactoring, because it allows you to exploit duplication within your data to reduce the size and improve the richness of your object graph at the same time.


For example, if there are many messages with the same author, it would be worth separating the author into a separate entity and just using a relationship. Not only does this mean you're storing slightly less raw data per email instance, it also means you can get at all of the messages an author has written just by traversing a relationship.

It's also very important to note that with Core Data you generally don't need to maintain your own "unique ID" mechanisms. Each object gets a unique ID, its managed object ID, from Core Data. You don't need to maintain these, use them to perform your own joins or relationship maintenance, etc. -- just work with the objects as objects, and let Core Data handle the rest.

can anyone point me on any direction to improve performance ? or is SQLite a very poor choice from apple ?

SQLite can perform quite nicely in situations with a great many objects and well over 15MB of data. There's nothing obviously amiss in the code that you've shown. Is your code multithreaded, with something else manipulating the same persistent store at the same time? What does your data model look like in more detail? And finally, what version of Mac OS X are you using?


  -- Chris

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Core Data Fetch request very poor performance ??!
      • From: Ruslan Zasukhin <email@hidden>
    • Re: Core Data Fetch request very poor performance ??!
      • From: Aurélien Hugelé <email@hidden>
References: 
 >Core Data Fetch request very poor performance ??! (From: Aurélien Hugelé <email@hidden>)

  • Prev by Date: Core Data Fetch request very poor performance ??!
  • Next by Date: Re: [NSApp mainMenu] returns nil under 10.4.3
  • Previous by thread: Core Data Fetch request very poor performance ??!
  • Next by thread: Re: Core Data Fetch request very poor performance ??!
  • Index(es):
    • Date
    • Thread