iPhoneの開発では、速度が重要です。CoreFoundationタイプ(CFMutableDictionaryRefなど)とFoundationタイプ(対応するNSMutableDictionary)の使用に速度の違いがあるかどうかは誰にもわかりません。
CFタイプの操作は、ObjCランタイムメッセージをスローする必要がないため、より高速になると思います。これは根拠のない仮定ですか、誰かが実際にこれを調べましたか?
iPhoneの開発では、速度が重要です。CoreFoundationタイプ(CFMutableDictionaryRefなど)とFoundationタイプ(対応するNSMutableDictionary)の使用に速度の違いがあるかどうかは誰にもわかりません。
CFタイプの操作は、ObjCランタイムメッセージをスローする必要がないため、より高速になると思います。これは根拠のない仮定ですか、誰かが実際にこれを調べましたか?
技術的な意味では、そうです、まさにその理由で、より高速です。
実用的な意味では、いいえ、それは速くはありません。一つには、速度差はごくわずかです。プロセス全体の存続期間中に節約されたミリ秒について話しています。
節約はiPhoneの方が大きいかもしれませんが、それでもあなたが得ることができる最も小さな速度の増加です。あなたの時間は、Instrumentsでアプリのプロファイリングを行い、アプリが指示する場所に移動して、独自のコードのホットスポットを解決するために費やす方がはるかに優れています。
そして、それがFoundationがより速くなるところです:あなたの時間。
可能な限りFoundationの自動解放機能を使用するコードは、簡単に回避できるメモリリーク(つまり、メッセージの書き込みを忘れたり、release
メッセージに到達できなかったりすること)を回避することで、多くの時間と頭痛の種を節約します。CFには自動リリースがないため、CFでCFRelease
作成またはコピーするすべてのものを明示的に覚えておく必要があります。そのコードを忘れたり、到達できなかったりすると(つまり、経験から言えば)、はるかに多くの時間を費やすことになります。メモリリークを追跡します。静的アナライザーは役立ちますが、すべてをキャッチすることはできません。
(技術的にはCFオブジェクトを自動解放できますが、そうするためのコードはひどく醜く、すでにわずかな速度の向上に水を差すだけです。)
ですから、可能な限り財団に固執してください。自動リリースでやりすぎないでください。純粋なCocoaでも、オブジェクトを明示的に解放する必要がある場合があります(ほとんどの場合、タイトなループ)。これは、Cocoa Touchでは2倍になります(メモリを割り当てすぎるとiOSがアプリを強制終了するため、大量に解放する必要があります)できるだけ早く画像のようなオブジェクト)。ただし、通常、自動リリースは、CFがユーザーを節約するよりもはるかに多くの時間を節約します。
時間に関係のない理由は、(メッセージセレクターからの)引数名が値と混合されたObjective-Cコードは、C関数ベースのコードよりもはるかに読みやすいためです。これで作業が速くなることはないかもしれませんが、確かにもっと楽しくなります。
CF関数でコードを書くと、アプリのパフォーマンスが実際に向上する可能性がありますが、究極のパフォーマンスの向上が本当に必要な場合は、マシンコードで直接コードを書くだけで、それより速くなることはありません。これは極端なアプローチですが。
少なくともPeterHoseyが言及した理由から、高水準言語構造は低水準言語構造よりも望ましいです。これに、プロジェクトの失敗につながる可能性のある時期尚早の最適化を追加できます。これは、開発者が機能的な側面ではなく、アプリケーションの非機能的な側面に関心を持っているためです。
完全に機能するアプリを入手した後、コードの一部にパフォーマンスのボトルネックがあると感じた場合は、それらを低レベルの言語構造に書き直すことで、それらを最適化することができます。低レベルのコードが期待どおりに動作することを確認するために、少なくとも現在のコードとの比較ポイントがあります(手動テストまたは単体テストのいずれかでここでうまくいきます)。
私が言おうとしているのは、パフォーマンスを無視するべきではありませんが、これを最初の目標にするべきではないということです。機能的な側面も重要です(それ以上ではありません)。機能仕様を提供するアプリがない場合は、地球上で最速である可能性があり、人々はそれを使用しません。