Objective-Cのメッセージディスパッチおよびその他の機能は、それらが提供するものに合わせて調整されており、かなり高速ですが、それでも、計算タスクのために調整されたCの可能性に近づいていません。
NSNumber *a = [NSNumber numberWithIntegerValue:(b.integerValue + c.integerValue)];
よりもはるかに遅いです:
NSInteger a = b + c;
そして、その理由で、Objective-Cのオブジェクトに対して実際に数学を行う人は誰もいません(それと構文はひどいです)。
Objective-Cの力は、高価なビットを捨てて、必要なときに純粋なCを使用できる、表現力豊かなメッセージベースのオブジェクトシステムを備えていることです。KVOは高価なビットの1つです。私はKVOが大好きで、いつも使っています。特に観測対象が多い場合は、計算コストが高くなります。
内側のループとは、あなたが何度も何度も実行する小さなコードであり、そこで行われることは何でも何度も繰り返されます。これは、必要に応じてOOP機能を削除する必要がある場所、メモリを割り当てない場所、メソッド呼び出しを静的インライン関数に置き換えることを検討する場所です。レンダリングループで許容できるパフォーマンスを得ることができたとしても、高価な通知とディスパッチロジックをすべて取得した場合よりもパフォーマンスが大幅に低下します。
あなたが本当にKVOでそれを続けたいのなら、ここにあなたが物事をより速く進めるために試みることができるいくつかのことがあります:
- オブジェクトの自動KVOから手動KVOに切り替えます。これにより、誤った通知を減らすことができます
- 更新の集計:一定の時間間隔での中間値が関連性がなく、(次のアニメーションフレームのように)一定時間延期できる場合は、変更を投稿しないでください。変更を投稿する必要があることをマークして、関連するタイマーがオフになると、短期間の中間更新の束を回避できる可能性があります。また、ある種のプロキシを使用して、複数のオブジェクト間の関連する変更を集約することもできます。
- 監視可能なプロパティをマージする:変更される可能性のある1つのタイプのオブジェクトに多数のプロパティがある場合は、単一の「hasChanges」プロパティを監視し、オブザーバーにプロパティをクエリさせる方がよい場合があります。