は、仮想的なOOP言語でこのような状況を考えてみましょう：
class A {
say_something(){
print("A!")
}
do_something(){
say_something()
}
}
と
class B : extends A {
say_something(){
print("B!")
}
}
は今、あなたはBのインスタンスを持っていると仮定し、do_somethingを呼び出す：
B b;
b.do_something();
万一bAまたはを印刷？ do_somethingの実装におけるsay_somethingの呼び出しがvtable（C++）またはobj_msgSend（Obj-C）の場合はBと表示されますが、コンパイラが同じクラスのメソッドの呼び出しで同じクラスのメソッドであれば、Aを出力します。
これは望ましい状況によって異なります。したがって、C++では、メンバー関数virtualをマークすることで、選択肢を持つことができます。 Objective-Cでは、すべてのメソッドが仮想です。
したがって、C++でも、提案した最適化は仮想メソッドには行われません。私は仮想メソッドなしで適切なOOP言語を言いません。
とにかく、Obj-Cアプリケーションのパフォーマンスが低下すると心配するかもしれません。 Appleは危険を知っているので、たくさんの最適化があります。たとえば、最近のランタイムではobjc_msgSendが固定アドレスに存在するため、まず共有ライブラリの境界を通過する必要はありません。
ミュールキバネティックスの記事も素晴らしかったですが、それは非常に年代が古いことにも注意してください。これは10年前のことです。これは、このビジネスの前史時代です。 objc_msgSendの実装に最近追加された最適化については、bbum's blog postsまたはHamster's blog postsで読むことができます。
UIを管理するコードを作成する場合は、標準のメッセージング（つまり、舞台裏でobjc_msgSend）は完全に適切です。モバイル機器でも非常にスムーズに動作します。だから、コードの性能を測定した後で絶対に必要になるまで、IMPなどを取得して早すぎる最適化をしないでください。
たとえば、数万の粒子が動いている計算集約的なコードを書いているなら、私はObj-Cメッセージングフレームワークの使用についてアドバイスをします。その場合は、Objective-C++で使用できるCコード（Objective-Cでは常に使用可能）またはC++コード（Objective-C++で使用可能）を記述するだけです。
IMPを参照してください。クラス内のすべての呼び出しでこれを行うのはどんな混乱ですか？しかし、コンパイラーはインスタンスがコンパイル時にそれ自身を呼び出すことを理解できませんか？非常に奇妙な。つまり、セレクタ構文を使用して同じインスタンスのメソッドを呼び出す必要はありません。 – P5music
@ P5music：C++の場合でも、クラスのメンバー関数の実装内部からのクラスの仮想メソッドの呼び出しは、仮想関数テーブルを経由します。 Objective-Cでは、すべてのメソッド呼び出しは仮想です。したがって、 'objc_msgSend'ファシリティを呼び出します。心配しないで、Appleは「objc_msgSend」が絶対に重要だと知っていますので、手作りのアセンブリとたくさんのハッキングを使って完全に調整するために多くの努力を払っています。 – Yuji