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: Aurélien Hugelé <email@hidden>
- Date: Tue, 29 Nov 2005 11:08:15 +0100
On 29 nov. 05, at 08:56, Chris Hanson wrote:
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?
i'm using official 10.4.3
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.)
you are right on this point, but my application has a background, and
needs data migration from archive to sql database... i'm using the
good old "find and create" technique, so i load everything in memory,
find if it as already been stored in the database, and create it if
necessary...
I've of course read your several notes/messages/enhancements about
this technique (you proposed some nice ideas by the way in those
notes, thank you).
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.
Yes, from a fresh point of view, i agree... but as i said, my
application is already written and working... i need to keep
compatibility with my older controller... i just modified some part
of my controllers to have wrapper over core data. That's why i have
very few relation ships : my Author object already exists (it is a
wrapper above AddressBook's ABPerson) and it is not easy to break
everything just for core data :P
Moreover, thanks to uniqueIds, i can resolve *at run time* the name
(and many other things) of the author (that can have been modified by
another application!). I do not store persons datas myself since i'm
based on AddressBook framework.
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?
nothing particularly threaded, on OS X 10.4.3. My data model is
*very* simple : 2 entities first one is Record, with attributes only :
uniqueId, creation date, modification date, linked people (of the
AddressBook), comment (a note), a duration (if applicable), a format
version, a subject, a summary, pathes to linked files (if any),
colors (to visually have color when the record is displayed), a
direction (in or out)
second one is Email, sub entity of Record , attributes only :
mail account path, mailbox path, sender, recipients.
for compatibility reason, i do not use to-many relation ships,
because of my old code that used to directly modify the pathes to
linked files, colors, recipients.
So I have a question here...
consider the Author entity above, and Recipients too. Obviously,
since my application was written long before bindings and core data
(since beginning of 10.2, and is based on Apple AddressBook database
i could not design it with these technology in mind...
rewritting these objects now would require (i think) a lot of work, i
can not do immediatly, maybe later.
I would like opinions about entities properties and their design :
As i said above, Author and Recipients were, in my previous version,
NSMutableSet of uniqueIds (as NSString*) matching the ABPerson
uniqueIds in the addressbook, this allow the Person object to be
resolved at runtime with lastest informations from AddressBook.
Now that i use core data, and can not rewrite everything from
scratch, how should i link persons to emails ? how can i use an
Author entity and Recipients entity to keep compatibility ? should
those entity only have one attribute which is "uniqueId", containing
the ABPerson uniqueId string ? is it better to archive/dearchiving
NSMutableSet of uniqueIds as an attribute of my Email entity (like
this i do not need to change anything in my older controller)?
I just feel it poor to use to-many relations ships to entities that
just have one attribute...
Aurelien _______________________________________________
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