4

iPhone プラットフォームの Objective-C にオブジェクト グラフがあり、アプリを閉じるときにフラッシュを保持したいと考えています。グラフには約 100k ～ 200k のオブジェクトがあり、多くのループが含まれています (設計による)。このグラフをできるだけ早く読み書きできるようにする必要があります。

これまでのところ、NSCoder を使用してみました。これはループに苦労するだけでなく、グラフを永続化するのに時間がかかり、かなりの量のメモリが必要になります。これはおそらく、XML ドキュメントが内部で使用されているためです。SQLite データベースも使用しましたが、その多くの行をステップ実行するのにもかなりの時間がかかります。

Core-Data の使用を検討しましたが、core-data へのバッキング ストアが同じように機能すると考えているため、SQLite や NSCoder と同じ問題が発生するのではないかと心配しています。

このオブジェクトグラフの永続性を軽量な方法で処理できる他の方法はありますか?理想的には、Javaのシリアライゼーションのようなものが欲しいですか? 私はTokyo Cabinetを試すか、C 構造体の束によって占有されているメモリをディスクに書き込むことを考えていましたが、それは多くの書き直し作業になるでしょう。

4

2 に答える 2

1

自分で作成するのではなく、CoreDataをもう一度確認することを強くお勧めします。Core Dataは、オブジェクトグラフを永続化するためにゼロから設計されました。あなたが説明するようなNSCoderベースのアーカイブでは、オブジェクトグラフ全体をメモリに保存する必要があり、すべての書き込みはアトミックです。Core Dataは、必要に応じてオブジェクトをメモリに出し入れし、（SQLiteを介して）ディスクに変更されたグラフの部分のみを書き込むことができます。

Core Dataプログラミングガイドまたはそのチュートリアルガイドを読むと、パフォーマンスの最適化に多くの考慮が払われていることがわかります。Appleの推奨事項（ある時点でデータ構造を非正規化するという提案のように、直感に反しているように見える場合があります）に従うと、データモデルから予想よりもはるかに多くのパフォーマンスを引き出すことができます。私は、CoreDataがあなたが見ているサイズのデータ​​ベース内のデータアクセスのために手作業で調整されたSQLiteを手軽に打ち負かすベンチマークを見てきました。

iPhoneでは、フェッチのバッチサイズの制御と、NSFetchedResultsControllerの非常に優れたヘルパークラスを使用するときに、メモリの利点もいくつかあります。

グラフの原理実証コアデータ実装を構築して、既存のデータストレージ方法と比較するのにそれほど時間はかからないはずです。

于 2009-08-18T13:11:48.190 に答える
1

C構造体として書き直すことをお勧めします。面倒なことはわかっていますが、ディスクへの書き込みが高速になるだけでなく、パフォーマンスも大幅に向上するはずです。

混乱する前に言っておきますが、常に構造体を使用するべきだと言っているわけではありませんが、実際には構造体の方がパフォーマンスが向上する場合があります。特に、繰り返しループ内で多くの小さなチャンクを作成/割り当てるのではなく、一度に 20k の連続したブロック (ブロックへのポインターを使用) でメモリを事前に割り当てる場合。

つまり、ループが継続的にオブジェクトを割り当てると、速度が低下します。1000 個の構造体を事前に割り当てていて、ポインターの配列 (または単一のポインター) しかない場合、これは大幅に高速になります。

(デスクトップ mac でさえ遅すぎて、連続して作成される何百万ものオブジェクトに対処するのに十分なメモリがないという状況がありました)

于 2009-08-18T12:45:01.400 に答える