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: Juanjo Conti <email@hidden>
- Date: Thu, 06 Aug 2015 10:36:02 -0300
I've checked the number of entries and is only 350. They are regular
cookies for well known sites like google, new relic, twitter...
I detect the performance issue using Instruments to mesure CPU time. The
heaviest call from my call resulted to [CookieKey encodeWithCoder:] which
current implementation is:
- (void)encodeWithCoder:(NSCoder *)encoder {
[encoder encodeObject:self.domain forKey:COOKIE_KEY_DOMAIN_KEY];
[encoder encodeObject:self.path forKey:COOKIE_KEY_PATH_KEY];
[encoder encodeObject:self.name forKey:COOKIE_KEY_NAME_KEY];
}
This is part of a CookieStorage class replacement, so I read/write the hole
storage each time a cookie is set or deleted.
CookieKey do implement the methods you mention.
- (NSUInteger)hash {
return self.domain.hash ^ self.path.hash ^ self.name.hash;
}
- (BOOL)isEqual:(id)other {
if (![other isKindOfClass:[CookieKey class]]) {
return NO;
}
CookieKey *otherCookieKey = (CookieKey *)other;
return [self.domain isEqual: otherCookieKey.domain] && [self.path
isEqual: otherCookieKey.path] && [self.name isEqual: otherCookieKey.name];
}
Thanks,
On Thu, Aug 6, 2015 at 7:53 AM, Uli Kusterer <email@hidden>
wrote:
> 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
>
>
>
>
>
--
Juanjo Conti <jjconti <http://goog_2023646312>@carouselapps.com
<email@hidden>>
Software Engineer - Carousel Apps <https://carouselapps.com>
--
Carousel Apps Limited, registered in England & Wales with registered number
7689440 and registered office Unit 2 Artbrand Studios, 7 Leathermarket
Street, London SE1 3HN. Any communication sent by or on behalf of Carousel
App Ltd or any of its subsidiary, holding or affiliated companies or
entities (together "Watu") is confidential and may be privileged or
otherwise protected. If you receive it in error please inform us and then
delete it from your system. You should not copy it or disclose its contents
to anyone. Messages sent to and from Watu may be monitored to ensure
compliance with our internal policies and to protect our business. Emails
are not secure and cannot be guaranteed to be error free. Anyone who
communicates with us by email is taken to accept these risks.
_______________________________________________
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