問題タブ [heap-fragmentation]

ヒープの断片化の回避に関する多くの記事を認識しています。私の質問は、ベクトルを使用してデータを保存するときに何が起こるかということと関係があります。

new または delete の使用に問題はありません (メモリ リークはありません。バーが使用されていない場合は非常に明確であり、必要に応じて delete を呼び出すことができます)。しかし、ヒープの断片化に関しては、どちらが優れていますか? これにより、スタック オーバーフローが発生しやすくなりますか?

編集：実際に追加する新しい情報はありません。皆さんに感謝したいと思います。C++ でタグ付けされた質問には、多くの知識豊富で親切な人が集まるようです。とても素敵です。ありがとうございました。

この問題を説明する簡単な例を次に示します (c++ を使用):

オブジェクトのサイズAが 3、オブジェクトのサイズBが 4、ヒープのサイズが 12 であるとしましょう。a2 を削除した後、メモリは次のようになります。

XXX---XXX---

B* bオブジェクトが連続していないため、十分なメモリがあってもオブジェクトを作成できません。

メモリの断片化の簡単な例です。

オブジェクトのメモリを「移動」して : の直後に置くreallocate()関数を作成することで、これを動的に回避できますか?a3

XXXXXX------

関数は明らかに削除後に呼び出す必要があるa2ため、再実装するdeallocate()かdelete()、これを行うことができます。どうすればこれを行うことができますか?

これは、私が扱っている問題の種類を示すための非常に単純な例です

150,000 個のファイルを分析するプログラムがあります。Valgrind はメモリ リークを報告しませんが、プログラムは時間の経過とともに遅くなります。

一部の問題は、std::string の使用頻度が高すぎたり、mktime に時間がかかりすぎたりすることに関連していました。( C++ が 70,000 ファイルの読み取りに時間の経過とともに遅くなる を参照)

しかし、それでも時間の経過とともに遅くなります。 Lotharyxは、コンテナーの使用がヒープの断片化を引き起こしていることを示唆しました。

さまざまな STL コンテナーの長所と短所に関するさまざまなフローチャートを読みましたが、よくわかりませんでした。

以下の疑似コードでは、ヒープの断片化を避けるために正しい選択をしたかどうか確信が持てません。

そして、上記のシーケンスは永遠に繰り返されます。

したがって、コンテナの選択のために、私は使用しました（または必要です）：

fileList-- 150,000 のパス名を含む一意の文字列のリスト。
std::set を選択したのは、重複を自動的に処理し、並べ替え順序を自動的に維持するためです。ランダム アクセスはなく、エントリを追加し、(手動または自動で) 並べ替え、それらを反復処理するだけです。

fileInfoMap-- ファイルの日付に対応する time_t タイムスタンプをキーとする構造体の配列。std::map を選択しました。これも 150,000 エントリになるため、多くのメモリを占有します。ランダム アクセスはありません。一方の端にエントリを追加するだけです。それらを反復処理し、必要に応じて途中からエントリを削除する必要があります。

eventList-- 「イベント」構造の小さなリスト、たとえば 50 項目。std::vector を選択しました。本当に理由がわからない。ランダムアクセスはありません。一方の端にエントリを追加するだけで、後でコレクションを反復処理します。

私はC ++にかなり慣れていません。ご検討いただきありがとうございます。