• 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: CoreData/NSManagedObject accessor performance problems
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CoreData/NSManagedObject accessor performance problems


  • Subject: Re: CoreData/NSManagedObject accessor performance problems
  • From: Scott Stevenson <email@hidden>
  • Date: Sat, 16 Dec 2006 06:53:32 -0800


On Dec 16, 2006, at 4:37 AM, Andrew Bush wrote:

first I attempted this by adding a predicate to the NSArrayController, but it appears to ignore the predicate when it is bound?

It might be worth trying to debug this before trying other options.


Ive tried creating a predicate to filter the object array by a single value, and that takes around the same time as doing the equivalent task with an enumerator..I assume both approaches are doing pretty much the exact same thing.

Instead of using selection directly, how about setting up a fetch request with a predicate that matches your filtering options _and_ also has the proper relationship to the parent object. Does that make sense?


In other words, don't bind to "selection" directly, but re-fetch when the selection changes.


the _really_ interesting thing is that repeating the filtering during the same running of the program, after altering one of the values I filter on and then calling [NSArrayController rearrangeObjects], appears to be a hell of a lot quicker.

Because everything is faulted in, probably?


so, on the wild, random guess that the slowdown is probably caused by some kind of serialisation being reversed for each initial call to each value of each object I am wondering whether it would make sense to create my own archiving strategy

That's a baby with the bathwater thing. A lot of people fall into the trap of thinking Core Data/Bindings is an "all or nothing" or "as-is" solution. It's not. There are plenty of opportunities for tweaking and customizing. I humbly suggest investigating other options before deciding that Core Data won't work here.


Apple has done a ton of work with Core Data. It's not perfect, but they have a lot of experience in data persistence and I believe many (if not most) issues people run into can be resolved with just a bit of patience and research. I especially say this because Core Data will continue to improve in subsequent OS releases and you can get all of that for free if you don't give up too easily.

In addition to the suggestion above, you might look into batch faulting. This document appears to discuss issues very much related to what you're doing:

<http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/ Articles/cdPerformance.html>

    - Scott
_______________________________________________

Cocoa-dev mailing list (email@hidden)

Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >CoreData/NSManagedObject accessor performance problems (From: Andrew Bush <email@hidden>)

  • Prev by Date: Re: Slider in menu (like System Volume)
  • Next by Date: Re: Efficient comparing of two directories
  • Previous by thread: CoreData/NSManagedObject accessor performance problems
  • Next by thread: Re: CoreData/NSManagedObject accessor performance problems
  • Index(es):
    • Date
    • Thread