Re: Performance with keyed archives
Re: Performance with keyed archives
- Subject: Re: Performance with keyed archives
- From: Scott Anguish <email@hidden>
- Date: Wed, 24 Nov 2004 20:57:23 -0500
On Nov 24, 2004, at 7:44 PM, Will Mason wrote:
I'm testing archving large collections of objects using both keyed and
unkeyed archives. In both cases I'm using the non-keyed coding methods
of NSCoder because I don't need to refer to all 10,000 objects by name
in the keyed archive. Each of the 10,000 objects is a pair of objects,
so in reality 20,000 objects are being coded. Here are timings of the
operations, and in all cases the exact same collection of objects is
being coded:
NSArchiver takes 0.344503 seconds to encode the collection.
NSUnarchiver takes 0.295801 seconds to decode the collection.
NSKeyedArchiver takes 41.806783 seconds to encode the collection.
NSKeyedUnarchiver takes 22.912641 seconds to decode the collection.
This means that NSKeyedArchiver is more than 121 times slower than
NSArchiver, and NSKeyedUnarchiver is more than 77 times slower than
NSUnarchiver.
My question is, can anything be done about this? Also, how can the
performance of NSKeyedArchiver be so pathetic even when it's encoding
things without keys? Also, with such an enormous performance difference
why are we being told in the documentation that keyed archives are to
be preferred, as surely there are situations where performance matters
to people?
Has anyone seen anything like this before? Can I improve the
performance?
I think there may be some issues as to how you're storing things...
The difference between keyed and 'unkeyed' is that keyed allow for
much easier handling of expanding fields in the future, and you can
even allow older applications to read newer file formats if you can
accept the loss of some information.
with an unkeyed version you need to store the version that you are
writing, and then read back the items in the correct order, skipping
superceeded fields. you have to read in all the data you wrote to be
able to read.
keyed allows you to read in only the required fields in an
object... if you junk old fields, then don't read them.. likewise, if
you read an older format, and it's missing data, provide default values
for those keys.
these are some of the reasons that they're suggested in the doc as
the preferred means.
Now, why is it so slow for you? well...
if you have an array of thousands of objects, you'd not store each
of those in a separate key, you'd archive the array.. each of those
individual objects would then archive it's contents, and eventually
when you have your custom objects, those would be archived using the
keyed encoder methods.
if you did store them using keys and tried to access them in some
random order, it'd be very slow.
another option is that you may be storing the keyed archives in the
XML format vs the binary format. that is likely much slower.
without seeing what you're doing exactly those are my first stabs
at the situation.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden