Re: Key-Value Observing speed
Re: Key-Value Observing speed
- Subject: Re: Key-Value Observing speed
- From: Mike Abdullah <email@hidden>
- Date: Sat, 13 Mar 2010 00:29:01 +0000
On 12 Mar 2010, at 23:32, Gwynne Raskind wrote:
> 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 :).
Almost certainly faster than NSInvocation. Although potentially more memory-intensive.
You could try overriding -valueForKey: to generate an NSValue as a shortcut. Means only adding to your existing 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
_______________________________________________
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