Re: NSKeyedArchiver finishEncoding takes forever
I also recommend logging a bug with Apple against this issue. You
shouldn't need to jump through those sorts of hoops with
NSKeyedArchiver.
On Wed, Jun 18, 2008 at 8:48 PM, Markus Spoettl
[EMAIL PROTECTED] wrote:
On Jun 18, 2008, at 2:41 PM, Michael Ash wrote:
Although it partially defeats the purpose of using NSCoder, you'll
avoid this whole path if you stuff all four doubles into a single
NSData. Don't forget to use the byte-swapping functions to ensure that
they all have a consistent representation across architectures.
Well, what can I say, you and Quincey Morris are absolutely right. This is
the way to go.
The same data set takes just 4 seconds to store with a file size of 17.2MB.
Thanks for all the help guys! For the record I'm posting the code below.
Regards
Markus
- (void)encodeDouble:(double)value forKey:(NSString *)key withCoder:(NSCoder
*)encoder
{
NSSwappedDouble sd = NSSwapHostDoubleToLittle(value);
[encoder encodeBytes:(const uint8_t *)sd length:sizeof(NSSwappedDouble)
forKey:key];
}
- (double)decodeDoubleForKey:(NSString *)key withCoder:(NSCoder *)decoder
{
double result = 0.0;
NSUInteger retsize;
NSSwappedDouble *sd = (NSSwappedDouble *)[decoder decodeBytesForKey:key
returnedLength:retsize];
if (retsize == sizeof(NSSwappedDouble)) {
result = NSSwapLittleDoubleToHost(*sd);
}
return result;
}
--
__
Markus Spoettl
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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/unmarked%40gmail.com
This email sent to [EMAIL PROTECTED]
--
Mark Munz
unmarked software
http://www.unmarked.com/
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: NSKeyedArchiver finishEncoding takes forever
On Jun 21, 2008, at 11:46 PM, Mark Munz wrote: I also recommend logging a bug with Apple against this issue. You shouldn't need to jump through those sorts of hoops with NSKeyedArchiver. I did (as requested by an Apple engineer). He told me that this has been fixed internally already, he couldn't say when it will be released, though. Regards Markus -- __ Markus Spoettl smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: NSKeyedArchiver finishEncoding takes forever
On Jun 18, 2008, at 7:08 PM, Markus Spoettl wrote:
On Jun 18, 2008, at 5:04 PM, Adam R. Maxwell wrote:
It's not recommended, but have you tried using old-style archiving
as another approach? It used to be considerably faster than keyed
archiving under some circumstances.
I have thought about trying this until I read it's deprecated since
10.2. Also they don't play well with changes to the data structure,
both very good reasons to stay away.
Apple still requires NSArchiver for NSPortCoder (Distributed Objects),
so it can't be completely deprecated. I agree that it doesn't play
well with changes to the data structure, but you'd only have to
implement it for the object with doubles as ivars, and still use
NSKeyedArchiver for the rest (example follows).
Not that you should do this, now that you've found another solution; I
was mainly curious to see if you saw any performance benefit from it,
and too lazy to write a test case and profile it for myself :).
--
adam
#import Foundation/Foundation.h
@interface TestObject : NSObject NSCoding
{
double a;
double b;
}
@end
@implementation TestObject
- (id)init
{
static double x = 0;
self = [super init];
if (self) {
a = x++;
b = x++;
}
return self;
}
- (NSString *)description
{
return [NSString stringWithFormat:@%@, a = %.3f, b = %.3f,
[super description], a, b];
}
- (id)initWithCoder:(NSCoder *)coder
{
self = [super init];
if (self) {
[coder decodeValueOfObjCType:@encode(double) at:a];
[coder decodeValueOfObjCType:@encode(double) at:b];
}
return self;
}
- (void)encodeWithCoder:(NSCoder *)coder
{
[coder encodeValueOfObjCType:@encode(double) at:a];
[coder encodeValueOfObjCType:@encode(double) at:b];
}
@end
@interface ParentObject: NSObject NSCoding
{
TestObject *child;
}
@end
@implementation ParentObject
- (id)init
{
self = [super init];
if (self) {
child = [TestObject new];
}
return self;
}
- (void)dealloc
{
[child release];
[super dealloc];
}
- (id)initWithCoder:(NSCoder *)coder
{
self = [super init];
if (self)
child = [[coder decodeObjectForKey:@child] retain];
return self;
}
- (void)encodeWithCoder:(NSCoder *)coder
{
[coder encodeObject:child forKey:@child];
}
- (NSString *)description
{
return [NSString stringWithFormat:@%@: child = %@, [super
description], child];
}
@end
int main (int argc, char const *argv[])
{
NSAutoreleasePool *pool = [NSAutoreleasePool new];
NSMutableArray *a = [NSMutableArray array];
int i;
for (i = 0; i 10; i++) {
ParentObject *obj = [ParentObject new];
[a addObject:obj];
[obj release];
}
NSLog(@1: %@, a);
NSData *d = [NSKeyedArchiver archivedDataWithRootObject:a];
NSLog(@archived to %d bytes, [d length]);
NSArray *b = [NSKeyedUnarchiver unarchiveObjectWithData:d];
NSLog(@2: %@, b);
[pool release];
return 0;
}
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: NSKeyedArchiver finishEncoding takes forever
Assuming you don't fix the issue: On Wed, Jun 18, 2008 at 2:13 PM, Markus Spoettl [EMAIL PROTECTED] wrote: 2) I also noticed that when I use the NSPropertyListXMLFormat_v1_0 instead of binary, the process speeds up considerably, taking just below 10 seconds. The problem with this is that the output file is huge (100 MB) which is too big for my purposes. Also, decoding the XML data is much slower than with binary data. Maybe serialize it to an XML plist data object, and then gzip that on a background thread? Won't help much with the decompression, I'm afraid. Or, you could grap an XML plist blob and then, on a background thread, reinstate that and write it out again as binary. This will consume a LOT of memory. I have this vision that you need to take a snapshot of the state of your object hierarchy at point X, so my suggestions might not be that helpful. It all has to do with what tradeoffs you're willing to make. Also, what OS and SDK are you using? --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: NSKeyedArchiver finishEncoding takes forever
On Jun 18, 2008, at 11:25 AM, Kyle Sluder wrote: On Wed, Jun 18, 2008 at 2:13 PM, Markus Spoettl [EMAIL PROTECTED] wrote: 2) I also noticed that when I use the NSPropertyListXMLFormat_v1_0 instead of binary, the process speeds up considerably, taking just below 10 seconds. The problem with this is that the output file is huge (100 MB) which is too big for my purposes. Also, decoding the XML data is much slower than with binary data. Maybe serialize it to an XML plist data object, and then gzip that on a background thread? Won't help much with the decompression, I'm afraid. Or, you could grap an XML plist blob and then, on a background thread, reinstate that and write it out again as binary. This will consume a LOT of memory. I have this vision that you need to take a snapshot of the state of your object hierarchy at point X, so my suggestions might not be that helpful. It all has to do with what tradeoffs you're willing to make. If there is no other solution to it, I may consider this. But I have a feeling there's something wrong with the doubles I encode which causes the whole mess. Anyway, thanks for the suggestion. Also, what OS and SDK are you using? Sorry I forgot. I'm on 10.5.3 using Xcode 3.0 and targeting 10.5+. Regards Markus -- __ Markus Spoettl smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: NSKeyedArchiver finishEncoding takes forever
On Wed, Jun 18, 2008 at 2:13 PM, Markus Spoettl [EMAIL PROTECTED] wrote: Hello List, I'm having a problem with a performance problem in NSKeyedArchiver which I can't find a cause for. I saw no mention in your message; have you profiled your app yet? Even though the time is not being spent in your code, a profile can give you an idea of what's taking up all this time, and may give you hints as to how to make it go faster. First response to any speed problem should always be to run Shark on it. Mike ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: NSKeyedArchiver finishEncoding takes forever
On Jun 18, 2008, at 12:35 PM, Michael Ash wrote: I saw no mention in your message; have you profiled your app yet? Even though the time is not being spent in your code, a profile can give you an idea of what's taking up all this time, and may give you hints as to how to make it go faster. First response to any speed problem should always be to run Shark on it. I did profile it but it's not my code that is slow. It's the call to [archiver finishEncoding] that's taking so long (see the Shark trace below. Regards Markus 0.0% 98.2% Foundation -[NSKeyedArchiver finishEncoding] 0.0% 98.2% CoreFoundation __CFBinaryPlistWriteToStream 0.0%98.2% CoreFoundation _flattenPlist 0.0%98.2% CoreFoundation _flattenPlist 0.0% 98.2% CoreFoundation _flattenPlist 0.0% 98.1% CoreFoundation _flattenPlist 0.0% 81.9% CoreFoundation CFSetAddValue 3.5% 57.0% CoreFoundation __CFSetFindBuckets2 2.6% 52.0% CoreFoundation __plistNumberEqual 4.0%27.9% CoreFoundation CFEqual 1.1% 23.7% CoreFoundation __CFNumberEqual 10.3% 22.6% CoreFoundation CFNumberCompare 6.9% 11.9% CoreFoundation __CFNumberGetValue 3.8% 3.8% commpage [libSystem.B.dylib] __memcpy 0.8% 0.8% CoreFoundation dyld_stub_memmove 0.4% 0.4% libSystem.B.dylib memmove 0.4% 0.4% commpage [libSystem.B.dylib] __memcpy 0.0% 0.0% CoreFoundation __CFNumberGetValue 0.2% 0.2% CoreFoundation CFNumberCompare 4.9% 20.5% CoreFoundation CFNumberIsFloatType 15.6% 15.6% CoreFoundation CFNumberGetType 0.6% 0.6% CoreFoundation CFNumberGetType 0.4% 0.4% CoreFoundation __CFNumberEqual 1.2% 1.2% CoreFoundation CFNumberIsFloatType 0.2%0.2%CoreFoundation CFEqual 0.0% 0.0% CoreFoundation __CFNumberHash 0.0% 0.0% CoreFoundation __CFStringHash 0.0%0.0%CoreFoundation _CFHash 0.0%0.0%CoreFoundation CFHash 0.0% 24.7% CoreFoundation __CFSetGrow 1.5% 24.6% CoreFoundation __CFSetFindBuckets2 0.1% 0.1% CoreFoundation __plistNumberEqual 0.0%0.0%CoreFoundation _CFHash 0.0% 0.0% CoreFoundation __CFNumberHash 0.3% 0.3% CoreFoundation __plistNumberEqual 0.0% 0.0% CoreFoundation __CFNumberHash 0.0% 16.0% CoreFoundation CFSetGetValue 1.2% 15.9% CoreFoundation __CFSetFindBuckets1b 1.1% 14.1% CoreFoundation __plistNumberEqual 2.0% 7.4% CoreFoundation CFNumberIsFloatType 0.8%5.4%CoreFoundation CFEqual 0.2% 0.2% CoreFoundation CFNumberGetType 0.1% 0.1% CoreFoundation __CFNumberEqual 0.4% 0.4% CoreFoundation CFNumberIsFloatType 0.0%0.0%CoreFoundation CFEqual 0.0% 0.0% CoreFoundation __CFStringHash 0.0% 0.0% CoreFoundation __CFNumberHash 0.0%0.0%CoreFoundation CFHash 0.0%0.0%CoreFoundation _CFHash 0.1% 0.1% CoreFoundation __plistNumberEqual 0.0% 0.0% CoreFoundation __CFNumberHash 0.0% 0.1% CoreFoundation CFArrayAppendValue 0.0% 0.1% CoreFoundation
Re: NSKeyedArchiver finishEncoding takes forever
On Jun 18, 2008, at 13:06, Markus Spoettl wrote: I did profile it but it's not my code that is slow. It's the call to [archiver finishEncoding] that's taking so long (see the Shark trace below. Regards Markus 3.5% 57.0% CoreFoundation __CFSetFindBuckets2 2.6% 52.0% CoreFoundation __plistNumberEqual 4.0% 27.9% CoreFoundation CFEqual 1.1% 23.7% CoreFoundation __CFNumberEqual 10.3% 22.6% CoreFoundation CFNumberCompare 6.9% 11.9% CoreFoundation __CFNumberGetValue 3.8% 3.8% commpage [libSystem.B.dylib] __memcpy ... 4.9% 20.5% CoreFoundation CFNumberIsFloatType 15.6% 15.6% CoreFoundation CFNumberGetType Yes, but look at where the time is *really* being spent. At a guess, finishEncoding is comparing every number object against every other number object to see if it can archive just one object of each distinct numeric value. With the number of objects you said you're using, this O(n**2) optimization -- if that's what it's doing -- is hideously expensive. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: NSKeyedArchiver finishEncoding takes forever
On Jun 18, 2008, at 1:59 PM, Quincey Morris wrote: Yes, but look at where the time is *really* being spent. At a guess, finishEncoding is comparing every number object against every other number object to see if it can archive just one object of each distinct numeric value. With the number of objects you said you're using, this O(n**2) optimization -- if that's what it's doing -- is hideously expensive. Exactly and the test data isn't particularly big. Any ideas how to tell the archiver not to do this with my doubles (that doesn't involve conversion to strings and back)? Regards Markus -- __ Markus Spoettl smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: NSKeyedArchiver finishEncoding takes forever
On Wed, Jun 18, 2008 at 5:17 PM, Markus Spoettl [EMAIL PROTECTED] wrote: On Jun 18, 2008, at 1:59 PM, Quincey Morris wrote: Yes, but look at where the time is *really* being spent. At a guess, finishEncoding is comparing every number object against every other number object to see if it can archive just one object of each distinct numeric value. With the number of objects you said you're using, this O(n**2) optimization -- if that's what it's doing -- is hideously expensive. Exactly and the test data isn't particularly big. Any ideas how to tell the archiver not to do this with my doubles (that doesn't involve conversion to strings and back)? Although it partially defeats the purpose of using NSCoder, you'll avoid this whole path if you stuff all four doubles into a single NSData. Don't forget to use the byte-swapping functions to ensure that they all have a consistent representation across architectures. Mike ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: NSKeyedArchiver finishEncoding takes forever
On Jun 18, 2008, at 14:17, Markus Spoettl wrote: Exactly and the test data isn't particularly big. Any ideas how to tell the archiver not to do this with my doubles (that doesn't involve conversion to strings and back)? I suppose you could byte-move each group of 4 doubles in one NSData and give that to the archiver instead. Or do it further upstream and make a bigger array of numbers in a NSData. (But you'll have to deal with endianness and -- egads! -- floating point representation issues across architectures yourself.) Perhaps you could avoid the endianness and representation issues by archiving each group of 4 doubles (with a different archive object) into a NSData and give that to your main archiver. This sounds like it would be slow, but probably not as slow as what you already tried. Probably the real answer is that NSKeyedArchiver isn't designed to handle such large numbers of objects efficiently. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: NSKeyedArchiver finishEncoding takes forever
On Jun 18, 2008, at 2:50 PM, Quincey Morris wrote: I suppose you could byte-move each group of 4 doubles in one NSData and give that to the archiver instead. Or do it further upstream and make a bigger array of numbers in a NSData. (But you'll have to deal with endianness and -- egads! -- floating point representation issues across architectures yourself.) Perhaps you could avoid the endianness and representation issues by archiving each group of 4 doubles (with a different archive object) into a NSData and give that to your main archiver. This sounds like it would be slow, but probably not as slow as what you already tried. I just tried this. It is slower than saving XML (around 10 seconds), which is orders of magnitudes faster than without this optimization. One problem is that each 4 double value object gets blown up to 307 bytes when in its NSData container. That makes the overall file increase from 18MB to 38MB. That's a bit of a problem and compressing the data won't make things faster, so that's not an option. I'll try the further upstream approach, it should lower the memory impact but I will pay for that with much slower performance - I'll report back how that turns out. Probably the real answer is that NSKeyedArchiver isn't designed to handle such large numbers of objects efficiently. It's more like lots of numbers rather than lots of objects. It doesn't matter whether the doubles are located in separate objects or not. Iit would be nice to see a warning in the documentation if such a design limitation really exists - it may be a bug. Anyway thanks for your input! Regards Markus -- __ Markus Spoettl smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: NSKeyedArchiver finishEncoding takes forever
On Jun 18, 2008, at 2:50 PM, Quincey Morris wrote: I suppose you could byte-move each group of 4 doubles in one NSData and give that to the archiver instead. Or do it further upstream and make a bigger array of numbers in a NSData. (But you'll have to deal with endianness and -- egads! -- floating point representation issues across architectures yourself.) I've now completed testing the third approach saving each ANode into it's own NSData and writing a number of those into the file archive: Optimization Write TimeFile Size - ---- None4:48 min 17.2 MB 4-double NSData 0:10 min 38.3 MB Upstream NSData 0:15 min 12.1 MB Surprisingly the file size is 1/3 smaller with the latest approach, the save time is still too long but much better than the original (almost 5 minutes). I'm not exactly sure about the speed, blocking the UI for 15 seconds isn't the best idea and the real data will be even bigger. So, a cure for NSKeyedArchiver's optimization would be great. Anyway, this is certainly interesting to learn all this, thanks for your help! Regards Markus -- __ Markus Spoettl smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: NSKeyedArchiver finishEncoding takes forever
On Jun 18, 2008, at 16:31, Markus Spoettl wrote: I'm not exactly sure about the speed, blocking the UI for 15 seconds isn't the best idea and the real data will be even bigger. So, a cure for NSKeyedArchiver's optimization would be great. The fastest, easiest approach would be to put your doubles as raw bytes into NSData objects, as Michael Ash suggested. Endianness should be easy to deal with, since you have the various NSSwap... functions to assist you. Perhaps floating point representation would not be an issue. It's years since I needed to know, but maybe all current Macs (Intel and PPC) use the same floating point representation for the 'double' type? The documentation, or a knowledgeable lurker, should be able to answer that for you. Or, manually decompose each double into a (56 bit?) integer mantissa and a (8 bit?) integer exponent. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: NSKeyedArchiver finishEncoding takes forever
On Jun 18, 2008, at 7:31 PM, Markus Spoettl wrote: On Jun 18, 2008, at 2:50 PM, Quincey Morris wrote: I suppose you could byte-move each group of 4 doubles in one NSData and give that to the archiver instead. Or do it further upstream and make a bigger array of numbers in a NSData. (But you'll have to deal with endianness and -- egads! -- floating point representation issues across architectures yourself.) I've now completed testing the third approach saving each ANode into it's own NSData and writing a number of those into the file archive: It's not recommended, but have you tried using old-style archiving as another approach? It used to be considerably faster than keyed archiving under some circumstances. -- Adam ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: NSKeyedArchiver finishEncoding takes forever
On Jun 18, 2008, at 5:04 PM, Adam R. Maxwell wrote: It's not recommended, but have you tried using old-style archiving as another approach? It used to be considerably faster than keyed archiving under some circumstances. I have thought about trying this until I read it's deprecated since 10.2. Also they don't play well with changes to the data structure, both very good reasons to stay away. Regards Markus -- __ Markus Spoettl smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: NSKeyedArchiver finishEncoding takes forever
On Jun 18, 2008, at 2:41 PM, Michael Ash wrote:
Although it partially defeats the purpose of using NSCoder, you'll
avoid this whole path if you stuff all four doubles into a single
NSData. Don't forget to use the byte-swapping functions to ensure that
they all have a consistent representation across architectures.
Well, what can I say, you and Quincey Morris are absolutely right.
This is the way to go.
The same data set takes just 4 seconds to store with a file size of
17.2MB.
Thanks for all the help guys! For the record I'm posting the code below.
Regards
Markus
- (void)encodeDouble:(double)value forKey:(NSString *)key withCoder:
(NSCoder *)encoder
{
NSSwappedDouble sd = NSSwapHostDoubleToLittle(value);
[encoder encodeBytes:(const uint8_t *)sd
length:sizeof(NSSwappedDouble) forKey:key];
}
- (double)decodeDoubleForKey:(NSString *)key withCoder:(NSCoder
*)decoder
{
double result = 0.0;
NSUInteger retsize;
NSSwappedDouble *sd = (NSSwappedDouble *)[decoder
decodeBytesForKey:key returnedLength:retsize];
if (retsize == sizeof(NSSwappedDouble)) {
result = NSSwapLittleDoubleToHost(*sd);
}
return result;
}
--
__
Markus Spoettl
smime.p7s
Description: S/MIME cryptographic signature
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: NSKeyedArchiver finishEncoding takes forever
On Wed, Jun 18, 2008 at 11:48 PM, Markus Spoettl [EMAIL PROTECTED] wrote: On Jun 18, 2008, at 2:41 PM, Michael Ash wrote: Although it partially defeats the purpose of using NSCoder, you'll avoid this whole path if you stuff all four doubles into a single NSData. Don't forget to use the byte-swapping functions to ensure that they all have a consistent representation across architectures. Well, what can I say, you and Quincey Morris are absolutely right. This is the way to go. The same data set takes just 4 seconds to store with a file size of 17.2MB. Thanks for all the help guys! For the record I'm posting the code below. I'm glad it all worked out for you. Just to address one last point, there should be no problems with floating point formats. As a practical matter, both PPC and x86 use the same IEEE754 floating point format, so the only problem is endianness. Any realistic future architecture is also likely to use this standard format. In a theoretical sense you should be protected regardless, because the swap functions you're using are explicitly made for floating point, so if there were any format differences then they would be expected to take care of them for you. Mike ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
