re: CoreData Performance Mystery
re: CoreData Performance Mystery
- Subject: re: CoreData Performance Mystery
- From: Mike McNamara <email@hidden>
- Date: Sun, 17 Feb 2008 11:35:18 -0700
At 3:38 PM -0800 2/16/08, Ben Trumbull wrote:
There are several previous discussions about using Shark,
Instruments, and plain old SQL logging to identify performance
problems using Core Data.
It doesn't appear as though my application is faulting in any way
however. In fact based on SQL logging, all of the SQL fetch related
activity taking place at great velocity. I have in fact been able to
cut the time required to move my Book objects from one genre to
another by using an NSSet vs. looping through the books:
// get genre based on the genre table row being dragged to
NSManagedObject *genreType;
// the array of book objects being dragged
NSArray *draggedBooks;
// looping through draggedBooks using an enumerator and changing
// the genre book by book is slow -- create an NSSet instead
NSSet *draggedSet = [NSSet setWithArray:draggedBooks];
// change the genre for the set
[draggedSet setValue:genreType forKey:@"genre"];
This cuts the move time in about half. So moving 200 books objects
now takes about 1.5 second vs. the 3 - 4 it was previously. Using
Instruments it appears to me that this 1.5 second period is almost
entirely related to KVO stuff like didChangeValueForKey. That seems
par for the course given that 200 relationships and inverse
relationships are changing buy I'm still somewhat surprised by how
long this takes? So I suppose it's more of a KVO performance issue
than a CoreData one.
Thank you Ben and Jens for your suggestions!
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