Re: Improve performance of data structure saved to disk
Re: Improve performance of data structure saved to disk
- Subject: Re: Improve performance of data structure saved to disk
- From: Uli Kusterer <email@hidden>
- Date: Thu, 06 Aug 2015 12:53:19 +0200
On 06 Aug 2015, at 05:17, Juanjo Conti <email@hidden> wrote:
> At the moment I'm using Keyed-Archiving, but after detecting performance
> issues and read I'm changing to Core-Data.
How did you detect these performance issues, and where exactly did it show you that keyed archiving is at fault?
> The data structure is a NSMutableDictionary in which keys are instantness
> of a custom class CookieKey and values and instances of NSHTTPCookie.
> CookieKey has 3 string properties (domain, path and name) and implements
> NSCoding protocol.
You are storing browser cookies and are seeing performance issues with keyed archivers? How many cookies do you have? Or are they somehow insanely large? How often do you read/write the whole storage?
Given keyed archiving is a generic, and forward-compatible way of storing objects, there are of course ways to create a more efficient implementation for a particular narrower case, but they're reasonably efficient for at least a couple hundred, maybe even thousands of objects, so I'm a bit skeptical that this really is your performance bottleneck.
> In the new implementation CookieKey will extend NSManagedObject and have
> the 3 string properties + a NSData one called cookie. And I'll work with a
> NSMutableArray.
>
> Is it a good idea? Another approach to use Core Data and improve
> performance?
It depends on your cookies and what makes them slow. If you have many cookies and you generally look them up by URL, CoreData might be the right approach. If your cookies are simply ridiculously large for a cookie, CoreData will probably make things worse. Storing NSData in a managed object is usually not the best idea, as you can't index the data, and the sqlite database underlying a CoreData store isn't really intended to store large blobs of data.
Without knowing how you diagnosed your performance issue and what part is actually slow (writing changed objects? Reading the list at startup? Looking up an entry?) we can't really make good suggestions.
My wild guess from what you've said so far is that you might have picked an unsuitable algorithm to look up your objects and that is what's slow. Does CookieKey (I hope that class has a prefix on its name in your actual code!) implement -compare:, -isEqual: and -hash? Does it implement NSCopying like a key should? How did you implement those? How are you looking up your objects (if that is what's slow)?
Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://stacksmith.org
_______________________________________________
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