2012-03-22 1 views
0

昨日投稿された質問へのフォローアップとして、Memory consumption of a pointer to vector of pointers、私はキータイプがあるboost ptr_mapのメモリ使用に関するもう一つの質問がありますクラスA(今のところintと仮定)とvalueは、ある種のポインタのベクトル(pointer to)になります。これはptr_mapです。私はSTLのマップのメモリ消費量は、一般的にクラスAのboost ptr_mapのキーとしてのメモリ消費と値Bのポインタのベクトル

(sizeof(A) + sizeof(B) + ELEMENT_OVERHEAD) * N + CONTAINER_OVERHEAD 

缶要素はオーバーヘッド

と仮定
sizeof(A) + sizeof(B) 

に関連して、このような設計のためにもどのように大きな私の質問の懸念であることを質問、How can i estimate memory usage of std::map?で読んだことがありますA型とB型(ここではAはintとし、Bはintへのポインタのベクトルへのポインタです)、通常のSTLマップの場合でも何らかの助けになるでしょう。また、可能ならば、Aがもっと複​​雑な場合、物事がどのように変化するかを知りたいと思っています.Aの複雑さとともに要素のオーバーヘッドが増えると思いますか?要素のオーバーヘッドは、AとBのサイズの合計の何分の一に制限されていますか?私の懸念は、要素のオーバーヘッドが本当に限定されていない大きな部分である場合、マップを使用する全体のポイントはもはや魅力的ではないように見えるということです。

+1

これらのオーバーヘッドは通常一定であり、キーと値とは無関係です。 –

+0

ありがとう..しかし、どのような要素のオーバーヘッド(私はコンテナのオーバーヘッドについて心配していない)は、sizeof(int)と比較してどのような考えですか?これはNを掛けるので、Nが大きければ大事です。 –

+0

サイズの大きいベクターで使用されているメモリと比較して小さい。 –

答えて

1

Martinho Fernandes氏は各地図アイテムのコメントオーバーヘッドで述べているように、一定です。いくつかの標準ライブラリの実装の調査後のマップ項目の

オーバーヘッド:

  • GCC 4.4.3:各ノードの3ポインタと1人の列挙型のメンバー
  • MSVC++ 2008、MSVC++ 2010:各ノードの3つのポインタと2つのチャー部材
  • 版STLPort 5.2.1:各ノード

GCC 4.4.3、MSVC++ 2008、MSVC++ 2010年版STLPort 5.2 3つのポインタと1つのBOOL部材。 1は地図を実装するために赤黒のツリーを使用します。

+0

wow ..あなたが言っていることに基づいて、キーとしてのintsのマップのためだけに、5,000万のサイズのマップを仮定します。ポインタのサイズは固定されており、コンテンツがすでにグローバルスコープ内にあるものを指していると仮定すると、消費されるメモリは少なくとも8,000 + 8 + 4 * 8 + enumのサイズです。私はシェルショックを受けています。 –

+0

@ squashed.bugabooあなたの5千万のベクトルがどれくらいのスペースを使っていると思いますか? –

+0

まあ、私のベクトルはポインタのベクトルです、各ポインタはグローバルスコープ内のデータを指しています..(追加のメモリは一切ありません)、通常これらのベクトルはそれぞれサイズ6です(したがって、私は8(int key)+ 8(vecへのポインタ)+ 4 * 8(vnmのノートに基づく)+ enums/etcのサイズを持っていました。これはうつ病です!オーバーヘッドが8 + 8のわずかな割合になることを望んでいた。 –

関連する問題