1

メインの Model クラスの @property として「Requests Buffer」クラスを使用しています。バッファーには遅延インスタンス化があり、バッファー モデルで処理する項目がない場合は、それを nil に設定します。複雑なバッファー オブジェクトの割り当てと割り当て解除に妥当な頻度があるかどうか疑問に思っていますか? そして、モデルのすべてのライフサイクル中にインスタンス変数に割り当てられたままにしておくことが理にかなっているのはいつでしょうか? 誰かが割り当ての背後にあるメカニズムを説明できるかもしれませんが、それは CPU を犠牲にして行われますか? お知らせ下さい。1 秒あたり約 5 ～ 10 の割り当て/割り当て解除があります。

4

2 に答える 2

2

あなたはそれを測定しましたか？サポートしているハードウェアの最も能力の低い部分に、ユーザーに明らかなパフォーマンスの問題がありますか? 低帯域幅/高遅延と高帯域幅/低遅延の両方の状況でテストしましたか?

最小電力構成と最大電力構成を使用した帯域幅構成全体でユーザーに明らかな問題がない場合、さらに追求することは [非常に価値のある] 教育的演習にすぎません。

問題がある場合、測定するまでパフォーマンスのボトルネックがどこにあるかを知る方法はありません。遅いとわからないものは最適化できません!

Allocations Instrument と CPU プロファイラー Instrument はどちらも、パフォーマンスを定量化するための優れたツールです。

適切なサイズの割り当ては、スレッド間の同期操作 (またはいくつか) を必要としますが、比較的安価です。新しいメモリの消費はコストがかかりますが、多くの割り当て/割り当て解除を伴うワーキング セットでのフラッタリングは通常、かなり高速です。割り当て/割り当て解除トラフィックが多いシステムでは、断片化が発生し、時間の経過とともにコストが高くなります。

于 2013-09-02T03:15:07.570 に答える
1

次のルールに従ってください。

  • きれいでよく構造化されたコードを書く
  • 動作させる
  • うまく機能しない場合は、プロファイリングしてボトルネックを特定します

その場合にのみ、最適化を検討してください。

複雑で遅い初期化または同期コードが含まれていない限り、1 秒あたり 5 ～ 10 回の割り当て/割り当て解除は、通常の状況では目立ちません。

于 2013-09-02T03:17:12.080 に答える