Re: Need of an Apple Engineer. Core-Data Issues
Re: Need of an Apple Engineer. Core-Data Issues
- Subject: Re: Need of an Apple Engineer. Core-Data Issues
- From: Scott Ellsworth <email@hidden>
- Date: Wed, 29 Mar 2006 11:09:23 -0800
On Mar 29, 2006, at 12:53 AM, malcom wrote:
Is there an Apple Engineer here?
Yep. As others have said, there are several that read the list on
their own time. They may choose, just like other readers, to answer
your question. To maximize that chance, you need to ask a question
they both can answer and will answer.
Before you start asking for official help, you might want to run
shark to see what is taking so much time. Shark is fairly easy to
use for the kind of test you need, and it can be launched right from
within xcode. You also might want to turn on sql debugging, as that
can then tell you whether it is retrieving a whole bunch of stuff one
row at a time, which is by bet. Then, if it is, you can prefetch.
If you shark it, and use the log, and do not come to a solution, you
can file a bug at bugreporter.apple.com, and someone will look at it
eventually. To maximize the effectiveness of such a bug report,
though, remove _everything_ from your project that is not absolutely
needed. For example, you might want to make a very simple cd app
with the distressing entity and a full store. Put a single button on
the interface that does the slow fetch, and report the time taken in
the console. Provide a data file, and zip it all up in the bug
report. That makes it really easy for people to understand and
reproduce your problem.
You can get a response much faster by contacting email@hidden with a
paid tech support incident. In the main, they get back within a day,
and they do good things. They are not cheap, but when you have a
killer problem, they can help a lot.
And now the third point. You need to post the code. You intrigued
me enough to look into the problem, but I had no way to test your
code here. So, even if you do not want to pay for a dts incident,
nor do you want to file a bug at bugreport.apple.com, you still might
want to make the simplest possible xcode project that shows the
problem, and to put up a data file to test it with.
To avoid long time loading (about 10 seconds in my MacBookPro...I
would not image what's happend on an "old" machine) I've tried to set
my old attributes as releationships.
I had a problem with an app where some gui things took forever, even
thought the store was only a few megs. Once I prefetched the
relationship targets before my draw loop, it took effectively no time.
With this technique I've saved a bit of time. Now it takes "only" 3
seconds at first fetch and during the other fetch results are
instantaneous (why? is there a sort of cache or what?).
Yep. Read some of the docs, especially about faulting. There are
several caches at various levels, but the one that is most likely to
impact you is the object cache that ties an object id to a blob of
memory. This is what faults try to read first, and if the object is
there, it can create a lot of objects in a second.
Is there a way to avoid this problem?
You have not isolated the problem yet, as best we can tell. Is it
running a lot of fetches, or one big fetch. Are the contained
strings small or large? How much data are we talking about, once it
is reconstituted into RAM, and is it all getting faulted right back
out before you use it? These questions, and more, can be answered
with Shark, the sql debug log, and a data file.
The performance guidelines inside CD programming guide is pretty short
and not detailed. My db with 8000 records weight about 15mb. It
contains article's subject, headers and body (strings).
A priori, this is not huge. I have had good performance from 100MB
stores. Of course, I wrote something with a 2M store that took
surprisingly long, because of how I navigated my relationships.
Simple to fix, but drove me up a tree until I did.
Need I to move body in another persistence store?
Unlikely - if it is at the other end of a relationship, and that
relationship is not faulted in, then you do not pay any overhead.
Is core-data made for "medium" size projects? (what mean medium? 15mb
seems to be small in my opinion)
I have used CD for some very large projects - million plus rows - and
gotten good performance, and I have written apps with just a few
thousand entities with absolutely awful performance. Thus far, every
poorly performing app could be turned into a well performing one with
minor changes, so I am happy thus far.
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