Plus for critical sections you can obtain method pointers which are just C functions.

The M1 chip has specialized paths on it just to make the message sending even faster. That’s part of the M1 magic.

To be fair I think the extent of this specialization is a branch hint

It’s still a kind of neat trick. One of those paths where even a little optimization goes a long way due to it being so hot.

as i recall, `libobjc` is ~25% of app launch time. `objc_msgSend` is quite expensive when you're making hundreds of thousands to millions of calls per second.

Although Swift has the spotlight, Objective-C keeps being improved.

"Advancements in the Objective-C runtime"

https://developer.apple.com/videos/play/wwdc2020/10163/

Swift uses the Objective-C runtime.

Swift can uses the Objective-C runtime for interoperability with Objective-C code, just like .NET uses COM on Windows.

They need to interoperate with the rest of the platform.

Swift is tiptoeing between static and dynamic typing, preferring the former when feasible, but often needing some of the latter when dealing with the UI.

I would guess that most of app startup time isn't going to objc_msgSend (although it is still probably slow as it hasn't warmed up yet) but rather to setting up the various data structures used by the runtime, applying initial swizzling and the associated cache invalidation that comes from that, and those pesky +loads that every analytics framework thinks it need to have ;)

The compiler does some very fancy stuff with objc_msgSend to make it fast, and the selectors are interned.

https://www.mikeash.com/pyblog/objc_msgsends-new-prototype.h...

Objective-C had an IMP pointer, essentially a function pointer. If you needed to send a message to an object in a tight loop, you could extract the pointer before the loop and use it inside.