• 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
CoreData Performance Mystery
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

CoreData Performance Mystery


  • Subject: CoreData Performance Mystery
  • From: Mike McNamara <email@hidden>
  • Date: Fri, 15 Feb 2008 21:26:16 -0700

Hello all -

I decided to take the plunge and write a CoreData app. I've been having a pretty good time of it, but have recently come across a performance issue that has me stumped.

I have two pretty basic entities, Genre and Book. You can imagine the Genre entity has a to-many Book relationship and the associated inverse. My test app has 2 table views, one with a Genre list and the other containing the Books for the currently selected Genre. I've implemented full drag and drop functionality so that books can be moved or copied from one Genre to another. Functionally this works perfectly. Performance wise it's fairly abysmal. Changing 200 books from one Genre to another takes roughly 4 seconds. This seems excessive? Basically my code for changing genres is as such:

// get genre based on the genre table row being dragged to
NSManagedObject *genreType;

// the array of book objects being dragged
NSArray *draggedBooks;

// this is literally all there is to the loop
NSEnumerator *enumerator;
enumerator = [draggedBooks objectEnumerator];
while (book = [enumerator nextObject]) {
    [book setValue:genreType forKey:@"genre"];
}

That above while loop appears to take nearly 1 second per 50 book objects. ??? This is using an SQLite store. Curiously selecting Undo from the Edit menu produces the inverse behavior in the blink of an eye. That led me to believe that perhaps the performance was a result of building up all of the inverse operations in the app's undoManager. So I set about setting the undoManager to nil and also disabling the undoManager using - disableUndoRegistration. While both worked as expected they failed to change the performance of switching genres in any appreciable way.

Is my approach to switching genres flawed or inefficient in some manner? Am I missing something? Again, *functionally* it appears to work perfectly. It's just the performance that seems really poor. The only thing keeping me sane is I notice similar performance when moving a similar number of objects between collections in Bare Bones cool app Yojimbo. Perhaps it's just the nature of the CoreData beast?

Advice, insight or RTFM URL's would be much appreciated!


Mike _______________________________________________

Cocoa-dev mailing list (email@hidden)

Please 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


  • Follow-Ups:
    • Re: CoreData Performance Mystery
      • From: Jens Alfke <email@hidden>
  • Prev by Date: Re: Plugin Bundle Strangeness - fixed
  • Next by Date: Re: Uncaught exceptions thrown by Cocoa documented anywhere?
  • Previous by thread: Re: Plugin Bundle Strangeness - fixed
  • Next by thread: Re: CoreData Performance Mystery
  • Index(es):
    • Date
    • Thread