• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Need of an Apple Engineer. Core-Data Issues
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


References: 
 >Need of an Apple Engineer. Core-Data Issues (From: malcom <email@hidden>)

  • Prev by Date: Re: optimizing bindings
  • Next by Date: Question about sheets...
  • Previous by thread: Re: Need of an Apple Engineer. Core-Data Issues
  • Next by thread: Re: Need of an Apple Engineer. Core-Data Issues
  • Index(es):
    • Date
    • Thread