Re: Future of Cocoa
Re: Future of Cocoa
- Subject: Re: Future of Cocoa
- From: Jean-Daniel via Cocoa-dev <email@hidden>
- Date: Mon, 16 Dec 2019 09:23:33 +0100
My bad, I just see that when rereading the description. Of course, it will
requires an updated runtime.
> Le 16 déc. 2019 à 09:21, Saagar Jha <email@hidden> a écrit :
>
> There’s also a check for method swizzling and other invalidation, assuming
> that there is cooperation from the runtime. Unless I’m misunderstanding what
> you mean by the selector changing?
>
> Saagar Jha
>
>> On Dec 16, 2019, at 00:16, Jean-Daniel <email@hidden
>> <mailto:email@hidden>> wrote:
>>
>>
>>> Le 16 déc. 2019 à 06:05, Saagar Jha <email@hidden
>>> <mailto:email@hidden>> a écrit :
>>>
>>> It’s been a while, but I just thought you both might be interested in some
>>> follow-up I did for this idea. I implemented it for fun in clang
>>> <https://github.com/saagarjha/expresscall> and it turns out that it’s a
>>> pretty decent performance win
>>> <https://saagarjha.com/blog/2019/12/15/bypassing-objc-msgsend/> over
>>> objc_msgSend, both because it dispatches faster and because the compiler
>>> can do a full inline through it.
>>
>> Yes, but you don't preserve the objc_msgSend semantic.
>>
>> If I understand you code correctly, all you do is checking if it is the same
>> ISA, which does not guarantee in anyway that the selector did not change
>> since the previous call.
>>
>> As classes are fully dynamic and methods can be swizzle, you must perform a
>> full IMP lookup for every calls, which complexly defeat the purpose of
>> inline caching.
>>
>
_______________________________________________
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