Re: performance of encoding an array of structs
Re: performance of encoding an array of structs
- Subject: Re: performance of encoding an array of structs
- From: Hank Heijink <email@hidden>
- Date: Tue, 12 Jun 2007 18:05:16 -0400
Thanks Dorian and Stephen!
I did read about this in the Apple docs, but the endian-problem held
me back. I thought there must be a simpler way, but maybe there
isn't. This program will run on PPC and Intel, but I guess the flag
should take care of it. I'll give it a whirl.
Cheers,
Hank
On Jun 12, 2007, at 2:36 PM, Dorian Johnson wrote:
Ah, that's true, I didn't think of that. That's only an issue if
the data have a possibility of being transfered between computers
of different architectures.
You can always set a flag in the coded data specifying the byte
ordering then flip it on the fly if needed when decoding. A bit
less elegant, but still far quicker (and it sounds like this is
somewhat critical, given the number of elements).
On Jun 12, 2007, at 1:23 PM, stephen joseph butler wrote:
On 6/12/07, Dorian J <email@hidden> wrote:
Basically, when you encode an NSArray, it puts it into a plist.
Since
you're using a c array, use an +[NSData dataWithBytesNoCopy:length:
] using _buffer and sizeof(MVTimedPoint) * _bufferSize as length and
store the resulting NSData. Then you can load the NSData straight
into your buffer when decoding. No converting to strings or plists,
just raw data. That should be a few orders of magnitude quicker.
Only do this if you don't care about clients running on an opposite
architecture. Your data won't load properly from Intel -> PPC, or PPC
-> Intel.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
40dorianjohnson.com
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
40runbox.com
This email sent to email@hidden
Hank Heijink
www.hankheijink.com
email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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