私はRuby出身で、単一責任の原則、カプセル化、疎結合、小さなテスト可能なメソッドなどの方法論を採用しているため、コードはメソッドからメソッドへと頻繁にジャンプする傾向があります。それが、Ruby の世界での作業に慣れている方法です。複数のことを行う「大規模な」メソッドを使い始めると、テストが非常に難しくなるため、これが主に BDD の場合に最適な方法であると私は主張します。
パフォーマンスの顕著な違いに関して、このアプローチに欠点があるかどうか疑問に思っていますか?
質問する
279 次
4 に答える
2
はい、インライン化するコンパイラがない限り、常にある程度のパフォーマンスへの影響がありますが、動的メソッド検索 (Ruby や Obj-C など) を行う場合はインライン化できないため、ある程度の影響があります。ただし、実際には言語と呼び出し規約に依存します。objc_msg_sendObjective-C で呼び出しを行う場合、オーバーヘッドは、C 呼び出し規則を 1 回使用する ( を呼び出す)、次にメソッド ルックアップ、そして何らかのジャンプ (おそらく C 呼び出し規則も使用する) のオーバーヘッドになることがわかっています。しかし、何でもかまいません）。ただし、C とアセンブリを作成していない限り、違いを確認することはほとんど不可能であることを覚えておく必要があります。
于 2012-08-20T01:13:23.030 に答える
0
Objective-Cのメソッド呼び出しは比較的高価です（おそらく、C ++やJavaよりも少なくとも10倍遅くなります）。（実際、「ダックタイピング」などが原因で、標準のObjective-Cメソッド呼び出しがインライン化されているかどうかはわかりません。）
しかし、ほとんどの場合、Objective-CのパフォーマンスはUI操作（およびIO操作、およびネットワーク操作）によって支配されており、一般的なコードの効率は重要ではありません。集中的な計算を行っている場合にのみ、パフォーマンスが問題になります。
于 2012-08-20T02:37:25.437 に答える
0
必ずしも Object-C 固有であるとは限りませんが、非インタープリターまたは非動的ディスパッチ言語/ランタイムでコンパイラーによってインライン化されていないメソッド呼び出しが多すぎると、新しい関数へのすべての呼び出しで戻りアドレスをプッシュする必要があるため、パフォーマンスが低下します。スタックを作成し、呼び出し先が呼び出し元に戻ったときにクリーンアップする必要がある新しいスタック フレームを設定します。さらに、参照によって変数を渡す関数は、関数呼び出しがコンパイラにとって不透明であると見なされ、コンパイラが最適化を行う機能を削除するため、パフォーマンスが低下する可能性があります...つまり、コンパイラは読み取り/書き込み操作を並べ替えることができません変更可能な引数として関数に渡されるメモリ アドレスへの関数呼び出し (つまり、非constオブジェクト) 操作が再順序付けされた場合に危険を引き起こすメモリ アドレスに副作用が生じる可能性があるためです。
最終的には、これらのパフォーマンスの低下に実際に気付くのは、CPU バウンドのタイトなループの場合だけだと思います。たとえば、OS syscall を作成する関数呼び出しは、実際には、プログラムが OS スケジューラのタイム スライスを失うか、プリエンプトされる可能性があり、関数呼び出し自体よりも法外な時間がかかります。
于 2012-08-20T01:11:35.967 に答える
0
パフォーマンスへの影響があることは事実です。ただし、ほとんどのシステムのパフォーマンスは I/O によって支配されるため、メソッド ディスパッチのオーバーヘッドはパフォーマンス全体のごく一部です。メソッド ディスパッチのオーバーヘッドが大きいアプリを実行している場合は、より多くのディスパッチ オプションを備えた言語でのコーディングを検討できます。
于 2012-08-20T01:19:23.840 に答える