7


トピックが示唆しているように、膨大な量のデータをファイルにシリアライズするときに、boost::serialization でわずかな問題に遭遇しました。この問題は、アプリケーションのシリアル化部分のメモリ フットプリントが、シリアル化されているオブジェクトのメモリの約 3 倍から 3.5 倍を占めていることにあります。
私が持っているデータ構造は、基本クラスのポインターとその構造へのポインターの 3 次元ベクトルであることに注意することが重要です。このような:

using namespace std;    
vector<vector<vector<MyBase*> > >* data;

これは後でこれに似たコードでシリアル化されます。

ar & BOOST_SERIALIZATION_NVP(data);

boost/serialization/vector.hpp が含まれています。

シリアル化されるクラスはすべて「MyBase」から継承されます。
現在、私のプロジェクトの開始以来、典型的な binary_archive、text、xml、そして最終的にポリモーフィックな binary/xml/text とは異なるアーカイブをシリアライゼーションに使用してきました。これらのすべてがまったく同じように機能します。

通常、少量のデータをシリアル化する必要がある場合、これは問題にはなりませんが、私が持っているクラスの数は数百万 (理想的には約 1,000 万) であり、テストできたメモリ使用量は一貫してそれを示しています。コードの boost::serialization 部分によって割り当てられるメモリは、ファイルの書き込み中にアプリケーション全体のメモリ フットプリントの約 2/3 です。

これは、オブジェクト自体が 4.2GB を使用する 400 万個のオブジェクトに対して約 13.5 GB の RAM を使用することになります。これは、8 GB を超える物理 RAM を搭載したマシンにアクセスできないため、コードを取得できた限りです。また、これは Windows 7 プロフェッショナル x64 エディションで実行されている 64 ビット アプリケーションですが、Ubuntu ボックスでも状況は似ています。

シリアル化中ほど多くのメモリを使用しないアプリケーションのメモリ要件が非常に高いことは受け入れられないため、これをトラブルシューティングする方法は誰にでもわかります。

逆シリアル化は、必要なメモリの約 1.5 倍を割り当てるため、それほど悪くはありません。これは私が一緒に暮らすことができるものです。

boost::archive::archive_flags::no_tracking でトラッキングをオフにしようとしましたが、まったく同じように動作します。

誰が私が何をすべきか考えていますか?

4

1 に答える 1