Re: Key-Value Observing speed
Re: Key-Value Observing speed
- Subject: Re: Key-Value Observing speed
- From: Gwynne Raskind <email@hidden>
- Date: Fri, 12 Mar 2010 18:32:06 -0500
On Mar 12, 2010, at 5:49 PM, Greg Parker wrote:
>> You're right; the specific call that's causing the worst speed issues is returning a property typed with this structure:
>>
>> typedef struct { int32_t x, y; } IntegerPoint;
>>
>> It's not necessarily feasible to switch this to an NSPoint; it means digging up every point in the code that relies on signed 32-bit integer math and doing manual typecasting (or calling lround()) away from CGFloat. If there's no way to cheat KVO into doing this sanely, I'll resign myself to it, but I kinda hope there's something a little less annoying.
> Perhaps you can pack it in and out of a 64-bit integer? KVO might handle int64_t natively.
But then I'm back to changing every place in the code that looks at this property :).
On Mar 12, 2010, at 6:21 PM, Mike Abdullah wrote:
> What options are you using to observe this property? What if you have an additional method you bind to that returns an IntegerPoint already wrapped up in an NSValue or similar?
My options are 0; I don't need old or new values, or initial or prior notifications :). Is the cost of creating an autoreleased NSValue (there's a category on NSValue to wrap this struct, so that part's trivial at least) and extracting its value less than that of taking an NSInvocation? And that still doesn't solve taking apart the code :).
Lots of good ideas, but it sounds so far like my best bet is to just go back to an NSPoint, since it looks like I'll have to change everything in the code that uses it anyway.
-- Gwynne
_______________________________________________
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