Re: NSPredicate Matches
Re: NSPredicate Matches
- Subject: Re: NSPredicate Matches
- From: Keary Suska <email@hidden>
- Date: Thu, 17 Dec 2009 15:19:37 -0700
On Dec 17, 2009, at 11:03 AM, Gerriet M. Denkmann wrote:
> The problem: the first time it is used, this is very slow (about 20 seconds).
> There are 30 000 A entities, each have on average 2 B entities, each of these have about half a dozen C entities.
> In these 20 seconds the RSIZE increases by about 100 MB. Obviously the data gets cached in memory.
Core Data loads lazily, so this is probably the initial loading of data into memory. Shark it to get more specific information.
> I have another app, which uses the same data but not Core Data.
> Entity A corresponds to an NSDictionary which contains NSArrays (corresponding to B) which contain NSDictionaries containing NSStrings.
> This app seems to be as fast as the Core Data one, but has not this long delay at the first search.
If the data is already instantiated, you are already ahead of Core Data in this case.
> Could it be that Core Data is the wrong choice in this case? Or am I just using Core Data rather inefficiently?
Depends on what you are using Core Data for. It is not a database interface, and (IMHO) is ill suited to being one. If you are using it for only this purpose, you will likely find yourself fighting the API frequently. At least for database-intensive applications.
If you need features that Core Data provides such as the relational mapping and undo support, you may be served by using Core Data. If you are spending 80% of your time simulating cross-table joins, you may want to consider otherwise.
Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"
_______________________________________________
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