Re: [CORE DATA] batch faulting is very efficient, but...
Re: [CORE DATA] batch faulting is very efficient, but...
- Subject: Re: [CORE DATA] batch faulting is very efficient, but...
- From: Keith Wilson <email@hidden>
- Date: Thu, 9 Feb 2006 01:52:42 +1100
A Great post - thanks Aurélien, I'll have another go at the fetch
performance issue. Looks like you've cracked it.
In my case the batch faulting is only required occasionally so I do
not have your repeat performance problem.
You may like to refer to my post on http://www.cocoadev.com/index.pl?
CoreDataPerformance so that you know your are not alone in this
challenge.
Now you have solved that one maybe can you tell us a simple way to
managed mom changes across different versions of the application.
With these two problems solved (ie batch faulting and version
management) then CoreData is a real winner.
Keith from DownUnder
On 09/02/2006, at 1:19 AM, Aurélien Hugelé wrote:
Hi !
Yesterday, core data apple documentation was updated with a full
new article on core data performance tips.
Batch faulting tip was there from the beginning but was not clear
enough to be used correctly (the term "batch faulting" was
misunderstood by most readers on this list, we all hoped it would
fire faults very quickly, almost magically ;-) ).
Now that things are much clearer, (summary: batch faulting does not
fire faults, it simply put data for a fault in cache!) i succeeded
to use it, and it is *extremly* efficient :
- Without batch faulting: fresh start of the app: 35000 objects,
firing faults took about 35s because core data was performing a
separate round trip to the store.
- With batch faulting: fresh start of the app: 35000 objects, It
now takes about 800ms to fire my 35000 faults!!! whoah!!!
OK that's great, but this tips have negative impact too:
It decreases the fault firing time tremendously, but add a large
overhead (the time to execute the "self IN %@" fetch) for *all*
next calls to this method!
my method is supposed to return some objects (35 000 in my case)
the first time it is called, the objects are faults and are then
fired. Thanks to the batch faulting fetch (which takes about 2
seconds), faults firing is fast.
the next time it is called the objects are *not* faults, the batch
faulting fetch is executed, and takes again 2 seconds. The time
spent in this request is absolutly not useful because objects are
not faults!
I can conclude that batch faulting is extremly efficient when
objects are faults (eg, for the first access to datas) but add a
*very important* overhead (about 250%!!!) for all next access.
How can i know that the batch faulting request will be useful
(because data is not in cache) and how can i know that data is
cached so that there is no need to execute the batch faulting
request, and gain precious seconds ?
Currently i'm going to use an "isFault" filter to execute the batch
faulting request only on fault objects. (I know that an object can
be fault and be in cache at the same time)
what is the technique to execute the batch faulting request ONLY
when needed ??
Thanks for any help.
PS : i'm going to test pre-fetching too... I hope it will be as
efficient as batch faulting to fire my relation ship faults :-D
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40bigpond.net.au
This email sent to email@hidden
_______________________________________________
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