Re: [Core Data] Improve save performance ?
Re: [Core Data] Improve save performance ?
- Subject: Re: [Core Data] Improve save performance ?
- From: Eric Morand <email@hidden>
- Date: Tue, 17 Jan 2006 00:29:33 +0100
Storing one object is the worst case for a sql store, I suspect,
along with hitting every object in the store.
I wanted to pull out my managed object model from the equation so I
erased every entity there, and created only one with nor
relationships and no properties. I then scratched my sql file and
compiled and launched my test app. And, well, you are certainly
right, because it took 0.500 to save that poor little lonely managed
object to the persistent store !
Now, I'm sure that it's not model related but SQLite related.
That's a BIG flaw to me. I NEED every transaction (remember : I'm
creating and accounting software) created or modified by the use to
be saved immediately to the persistent store ! So I nearly always
have to store only one object at a time...and if it takes 0.5 second
to store, that's just unusable to me.
I'm pretty sure that this can't be normal. I've seen a lot of
application using core data and an SQLite store and they are very
responsive. I just can't believe their authors have taken the risk to
have the pending changes saved ONLY when the user quit the app. What
would happen if there is a power failure after 2 hours of work ? I've
never seen a core data application loose all the work of the user
when the app/computer crash...
If someone can help me, I'm un dire need of advices.
Eric.
Le 17 janv. 06 à 00:14, Scott Ellsworth a écrit :
On Jan 16, 2006, at 3:01 PM, Eric Morand wrote:
Thanks to both of you for the explanation. I'll try to learn using
Shark...
For now, I have some news : I've created a test Core Data app,
with the same managed object model than my official app.
I've then tries to save an object (of the same entity than the one
that takes so much time to save on my app) using an SQLite
persistent store and an XML one.
Here are the results :
- SQLite : around 0.450 second
- XML : around 0.005 second !!!
Try the same thing with a few hundred and a few thousand objects,
of which you only want to read/change a subset. Storing one object
is the worst case for a sql store, I suspect, along with hitting
every object in the store. Try it with a binary store, and I bet
it gets even faster.
Sql stores are very efficient, at least in my experience, when you
want to retrieve a subset of the total object list, especially if
there are strange conditions (predicates) that determine which ones
qualify.
Recent emails from mmalc, et al, to me have convinced me that it is
even fast to do a few thousand relationship traversals, as long as
a prior fetch fills the cache first. Faults are cheap if they do
not hit the database.
A second big win is the memory management. The SQL store only
keeps things in RAM that are currently in use. XML and binary
stores have to keep everything in RAM. If you only have one object
in the store, then this does not save much, but if you have
thousands of objects in the store, and only tens visible to the
user, then all the others live happily on disk.
In my case an XML persistent store is around 100 times faster than
SQLite !!!??? Is this normal ?
I will wait for the CD folks to chime in here.
Maybe there is something I'm doing wrong when creating my SQLite
persistent store. I thought a SQLite store was faster than XML store.
It is, but primarily at querying subsets when the data set is
larger than you really want in RAM at any one time.
I have found that the sql store takes longer than I am happy with
to write out 15k entities. Takes a minute for my app once the data
is loaded, and I really want that cut down some. I have been
meaning to turn on the sql log, and see whether it is a CD problem,
or one of my own.
Scott
_______________________________________________
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
=============================================
Automator Ketchup : http://automatorketchup.blogspot.com
_______________________________________________
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