Re: Core Data Fetch request very poor performance ??!
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