管理対象オブジェクト コンテキストがsave:メッセージを送信されるまで、管理対象オブジェクトに加えられた変更はメモリ内にのみ存在し、データベースにはコミットされません。では、データベースに対してどのようにクエリを実行するのでしょうか? 標準の SQL クエリを実行してから、保存されていないオブジェクトをクエリして結果をマージする必要があり、これは非常に遅くなるはずです。
更新: たとえば、記事 <-> タグの多対多の関係があり、保存されていない記事がいくつかあります。次に、いくつかのタグを持つ、またはいくつかの日付の間にあるすべての記事を見つけたいと思います。データベースでは、これは関係テーブルまたは日付フィールドに対するクエリであり、適切なインデックスを使用します。しかし、保存されていないオブジェクトの場合、保存されていないすべての記事および/またはそのタグを反復処理する必要がありますか? または、保存されていないオブジェクトの場合、データベースのようなストレージもありますか?
これは興味深い質問です。大量のオブジェクトがメモリ内にある場合、大量のフェッチがどれだけ効率的か疑問に思います。
私の推測では、メモリ内のオブジェクトはかなりインテリジェントに管理され、オブジェクト グラフはフェッチ リクエストのオーバーヘッドが最小限に抑えられるように設定されていると思います。すべてのオブジェクトがディスクに書き込まれた場合 (「ダブル フェッチ」のためだけに) は、効率がわずかに低下する可能性がありますが、全体として、メモリ レイヤーを使用することと、ディスクへの書き込みと読み取りを常に行う必要がないことの利点は次のようになります。これらのタイプのフェッチ要求のパフォーマンスのわずかな低下を大きく上回ります。
この質問に対する答えを得る唯一の方法は、自分で分析を行うことだと思います。Instruments を開くと、iOS シミュレーターにはフェッチ要求の分析に役立つ Core Data インストゥルメントがあります。同じフェッチを 2 回実行する場合の違いをテストします。1 回目はフェッチ前にすべての保留中の変更を処理し、もう 1 回はメモリ内のオブジェクトの束を処理します。これを行う場合は、2 つのフェッチの結果を確認したいと思います!
デフォルトでは、コア データはフェッチを実行するときに保留中の変更をクエリしませんsetIncludesPendingChanges。フェッチ リクエストのプロパティを使用して明示的に設定する必要があります。
これを有効にしていると仮定すると、保存されていない変更のクエリが遅くなると思う理由がわかりません。
Core Data インスタンスが SQLite ストアによってサポートされている場合は、永続ストレージ (ディスク) からデータベースを読み取る必要があります。保存されていないオブジェクトはすべて RAM に残ります。DB 内のオブジェクトにアクセスするよりも、保存されていないオブジェクトにアクセスする方がはるかに高速です。これら 2 つのクエリを並行して実行し、結果をマージすることができます。つまり、配列のマージは簡単です。つまり、パフォーマンスの低下は実質的にありません。
常に例外とエッジ ケースがありますが、一般的に言えば、顕著なパフォーマンスの低下はないはずです。