5

私は自分のコード全体で std::string オブジェクトを使用しており、それらのほとんどはスタックに割り当てられています。デフォルトの new/delete 演算子を置き換えて平均メモリ割り当てサイズをチェックしたところ、ほとんどの割り当てが std::string から来ていることに驚きました。これは非常に重要です。それらは 12 から 32 バイトです! これ（空きストレージから割り当てられた多数の小さな文字列）を最適化するために、私は簡単な解決策を思いつきました：

  • カスタム文字列クラスを実装する
  • 64 バイトなどの固定サイズの定義済みバッファを追加します (プロファイリング後にこのサイズを調整できます)。
  • 文字列の長さが 64 バイト未満の場合は定義済みのバッファを使用するか、より大きな文字列の場合は空きストレージから新しいバッファを割り当てます。

この実装では、長さ > 64 のすべての文字列に 64 バイトのメモリ オーバーヘッドを追加し、64 バイト未満の文字列には (64-lenth) オーバーヘッドも追加しますが、小さな文字列のすべての割り当てを防ぎます。

あなたはそのようなアプローチを試みましたか？割り当て時間/メモリの断片化を節約するために、ほとんどの場合、このメモリ オーバーヘッドをスタックに追加することは合理的ですか?

このアプローチは、カスタム str::string アロケーターよりも優れていますか?

4

3 に答える 3

7

それは合理的ですか？場合によります。継続的な割り当てと割り当て解除を使用して実際にメモリが不足していることに気付いていないstd::stringか、実際の(認識されているのではなく) パフォーマンスの問題を特定していない限り、これを行うのに時間を無駄にしていることになります。

誤解しないでいただきたいのですが、標準のアロケーターでは利用できない追加情報を使用することで、標準のアロケーターよりも大きな利益を得ることができます (そして、私はそうしています)。ただし、実際に修正する必要がある問題がない限り、標準的な方法を使用して、別の方法に時間を割いた方がよいでしょう。

于 2012-12-21T09:29:00.587 に答える
5

「 fbstringは std::string のドロップイン置換です。fbstring の主な利点は、事実上すべての重要なプリミティブでパフォーマンスが大幅に向上することです。」

https://github.com/facebook/folly/blob/master/folly/docs/FBString.md

これはかなり最適化されているはずです：

ストレージ戦略

小さな文字列 (<= 23 文字) は、メモリ割り当てなしでその場で保存されます。

中程度の文字列 (24 ～ 255 文字) は、malloc によって割り当てられたメモリに格納され、積極的にコピーされます。

大きな文字列 (> 255 文字) は、malloc によって割り当てられたメモリに格納され、遅延コピーされます。

于 2012-12-21T09:28:11.087 に答える
2

あなたはそのようなアプローチを試みましたか？

いいえ、しかし私は独自のアロケーターを書きました。それは私が好む代替手段です。

割り当て時間/メモリの断片化を節約するために、ほとんどの場合、このメモリ オーバーヘッドをスタックに追加することは合理的ですか?

「合理的」とは何かの定義は、状況によって異なります。メモリの断片化を防ぐ必要がありますか? 割り当て数を最小限にする必要がありますか? 文字列ごとに余分なメモリを犠牲にして速度を最大化しますか?

演習として std:: 実装を最適化したいだけですか?

パフォーマンス (またはメモリ) に制限のあるターゲット プラットフォームはありますか?

これらの各質問により、答えが変わります (メモリ オーバーヘッドが妥当かどうかについて)。

このアプローチは、カスタム str::string アロケーターよりも優れていますか?

状況によります。

于 2012-12-21T10:36:21.320 に答える