5

私は次のものを持っています：

class Obj;
typedef std::map<string, string> StrMap;
std::map<std::string, std::pair<Obj, StrMap> > complexMap;

問題は、complexMap の一部のエントリでは StrMap が空になり、まったく使用しないため、効率のために boost::optional を使用することを検討しています。私の質問は、boost::optional の効率はどのようなものかということです。残念ながら、その代価を支払うことで、最終的には何も得られないでしょう。

4

3 に答える 3

5

optional0 または 1 の値を保持できるコンテナーと考え​​てください。マップは既に、0 から N 個の要素を保持できるコンテナーです。したがって、オプションのマップは、0 から N 個の要素を保持できるコンテナー内のコンテナーです。さすがにここは何のメリットもありません。

空のマップのオーバーヘッドは非常に小さいです。マップは実際にはマップ ノードから内部的に構築されており、空のマップにはノードがありません。（各ノードが値を保持し、空のマップがデフォルト値を作成する方法がないため、できません）

于 2013-06-25T09:06:20.983 に答える
2

コメントを回答に移動...

オプションがどのように実装されているかを考えてみてください。通常は内部ストレージがあり (上記のコードのように、マップ オブジェクトを保持できるようにするため)、唯一の違いは、そのストレージにマップを構築しないことです。 -これは後で残します。ただし、オプションのオブジェクトを構築する必要があります。したがって、マップを作成するだけでなく、マップを使用していない場合に備えて、より大きなオプションのオブジェクトを作成しています。マップを使用する場合は、それも作成する必要があります。あなたはほとんど利益のためにもっと多くのことをしているようです.

理にかなっている場合がありますoptional(たとえば、戻り値、たとえば無効な状態を示したい場合、または複雑なメンバーの多くの初期化を行う非常に高価なコンストラクターがある場合)、自明なコンストラクターを持つオブジェクトの場合、オプションは実際にはコードが乱雑になる価値はありません。

免責事項: ただし、すべてのパフォーマンス関連の質問と同様に、プロフィール、プロフィール、そしてプロフィールをもう一度...

于 2013-06-25T08:25:20.213 に答える
2

「まばらな」計算を行っている場合は、次の 2 つのことを行うことができます。

  1. complexMap存在しない結果を大量に含む大きなものをboost::optional. これにより、要素ごとにスパース性がカプセル化されます。
  2. あなたunordered_mapのcomplexmMap. これにより、マップごとにまばらさがカプセル化されます。

代替案 1 は、プログラマーにとってより便利であり、スペースのオーバーヘッドを犠牲にしてほとんど必要としません。代替案 2 は、ほぼ完全にスペース効率が高くcomplexMap、可能な限り小さく保ちますが、前もってより多くのプログラミング作業が必要になります。

より受け入れやすい代替案を選択してください (ヒント: でギガバイト レベルの計算を行っている場合はcomplexMap、余分なレベルの間接化が報われるかもしれません。それ以外の場合は気にしません)。

boost::optionalデフォルトのコンストラクターや動的メモリ割り当てを必要としないため、スペースのオーバーヘッド以外に にかかるコストはほとんどありません。

于 2013-06-25T08:20:34.747 に答える