FROM : Mike Glass
DATE : Tue Feb 05 20:44:06 2008
We've found fetches to be inherently slow too. Generally though we're
not managing 150,000+ objects! Every time you do a fetch it involves a
round-trip to the persistent store. You might want to try using an
NSArrayController that will manage its own content, set it to manage
your MyEntity objects, and then use an NSPredicate on the results of
[arrayController arrangedObjects]; to filter it. We found that sped
things up immensely for our commonly used managed objects, and we
eliminated a lot of pointless round-trips to disk.
-Mike
On Feb 5, 2008, at 2:31 PM, James Hober wrote:
> I have a CoreData app that has a SQLite store holding 157,273
> managed objects. Each managed object has 2 attributes, input and
> answer, which are NSStrings and that's all. No other attributes.
> No relationships. No fetched properties.
>
> A simple fetch for a single managed object takes 7 seconds!
>
> NSPredicate *predicate = [NSPredicate predicateWithFormat:@"%K
> like %@",
> @"input", input]; //assume NSString *input exists
> NSFetchRequest *fetchRequest = [[[NSFetchRequest alloc] init]
> autorelease];
> NSEntityDescription *entity = [NSEntityDescription
> entityForName:@"MyEntity"
> inManagedObjectContext:
> [self managedObjectContext]];
> [fetchRequest setEntity:entity];
> [fetchRequest setPredicate:predicate];
> [fetchRequest setFetchLimit:1];
> NSError *error = nil;
>
> //The following line takes 7 seconds to execute:
> NSArray *results = [[self managedObjectContext]
> executeFetchRequest:fetchRequest error:&error];
>
> if ([results count]) {return [[results objectAtIndex:0]
> valueForKey:@"answer"];}
> return @"";
>
> How can I speed this up?
>
> The 157,273 inputs are unique. I believe CoreData searches them
> linearly in no particular order, instead of sorting them so they can
> be binary searched in the store. Is this aspect of CoreData
> opaque? Is there no way to get CoreData to efficiently search on a
> unique string attribute?
>
> If my experiments with CoreData continue to prove unfruitful, I may
> remain with my current implementation which uses Objective-C++ and
> an STL map. I can load all the data into the map in about 3.6
> seconds and then retrieval from memory is near instantaneous.
>
> Thank you for any help speeding up this CoreData implementation or
> any other suggestions.
> _______________________________________________
>
> Cocoa-dev mailing list (<email_removed>)
>
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/<email_removed>
>
> This email sent to <email_removed>
Mike Glass
Developer
Marware, Inc.
<email_removed>
http://www.projectx.com
http://www.marware.com
DATE : Tue Feb 05 20:44:06 2008
We've found fetches to be inherently slow too. Generally though we're
not managing 150,000+ objects! Every time you do a fetch it involves a
round-trip to the persistent store. You might want to try using an
NSArrayController that will manage its own content, set it to manage
your MyEntity objects, and then use an NSPredicate on the results of
[arrayController arrangedObjects]; to filter it. We found that sped
things up immensely for our commonly used managed objects, and we
eliminated a lot of pointless round-trips to disk.
-Mike
On Feb 5, 2008, at 2:31 PM, James Hober wrote:
> I have a CoreData app that has a SQLite store holding 157,273
> managed objects. Each managed object has 2 attributes, input and
> answer, which are NSStrings and that's all. No other attributes.
> No relationships. No fetched properties.
>
> A simple fetch for a single managed object takes 7 seconds!
>
> NSPredicate *predicate = [NSPredicate predicateWithFormat:@"%K
> like %@",
> @"input", input]; //assume NSString *input exists
> NSFetchRequest *fetchRequest = [[[NSFetchRequest alloc] init]
> autorelease];
> NSEntityDescription *entity = [NSEntityDescription
> entityForName:@"MyEntity"
> inManagedObjectContext:
> [self managedObjectContext]];
> [fetchRequest setEntity:entity];
> [fetchRequest setPredicate:predicate];
> [fetchRequest setFetchLimit:1];
> NSError *error = nil;
>
> //The following line takes 7 seconds to execute:
> NSArray *results = [[self managedObjectContext]
> executeFetchRequest:fetchRequest error:&error];
>
> if ([results count]) {return [[results objectAtIndex:0]
> valueForKey:@"answer"];}
> return @"";
>
> How can I speed this up?
>
> The 157,273 inputs are unique. I believe CoreData searches them
> linearly in no particular order, instead of sorting them so they can
> be binary searched in the store. Is this aspect of CoreData
> opaque? Is there no way to get CoreData to efficiently search on a
> unique string attribute?
>
> If my experiments with CoreData continue to prove unfruitful, I may
> remain with my current implementation which uses Objective-C++ and
> an STL map. I can load all the data into the map in about 3.6
> seconds and then retrieval from memory is near instantaneous.
>
> Thank you for any help speeding up this CoreData implementation or
> any other suggestions.
> _______________________________________________
>
> Cocoa-dev mailing list (<email_removed>)
>
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/<email_removed>
>
> This email sent to <email_removed>
Mike Glass
Developer
Marware, Inc.
<email_removed>
http://www.projectx.com
http://www.marware.com
| Related mails | Author | Date |
|---|---|---|
| James Hober | Feb 5, 20:31 | |
| Mike Glass | Feb 5, 20:44 | |
| Phil | Feb 5, 20:52 | |
| Bill Dudney | Feb 5, 20:58 | |
| Ben Trumbull | Feb 6, 01:07 | |
| James Hober | Feb 6, 19:24 |






Cocoa mail archive

