私は、STL を多用する非常に大規模なコンピューティング ライブラリに取り組んでいます。ライブラリは MSVC2003 を使用して構築されており、その STL 実装を使用しています。ライブラリのメモリ要件を下げ、パフォーマンスを向上させる代替の STL 実装を探しています。
現時点では、MSVC の新しいバージョンに切り替えることはできません。
可能であれば、ベンチマークに基づいていない実際の使用状況に関するフィードバックをお願いします。
EDIT：少し明確にするために、たとえば、一部のSTL実装（STLSoftなど）は、文字列連結の特定の最適化を提案しています。これらの影響は小さく聞こえるかもしれませんが、大きな改善につながる可能性があります。STLPort は、彼らが目標を明確に述べているもう 1 つの良い例です。最速の STL 実装がある、stdlib++ があるなど...これらはすべて良い候補になる可能性がありますが、すべてをテストする時間がありません。コミュニティの助けが必要です。その上で。
STL ポート。メモリ使用量の違いは測定していませんが、間違いなく高速です (実際の使用量です)。
新しいバージョンの MSVC に切り替えることはできないという基本的な前提に疑問を呈します。
新しい STL をダウンロードすることで、「無料で」メモリを減らしてパフォーマンスを向上させることはできないと思います。または、少なくとも、最新の MSVC に更新する場合と同じくらい多くのコード修正を行う必要があります。
長期的には、更新したいのは間違いありません...今すぐ更新してください。運が良ければ、そのメモリとパフォーマンスの一部を無料で手に入れることができます。
あなたが探しているとあなたが言うことに沿ってあなたに提案できる唯一のことは、私が良い（パフォーマンス！）と悪い（時々風変わりな！）経験をしたインテルコンパイラーを試すことです。と。
それ以外では、独自のメモリとパフォーマンスの問題を見つけ、カスタム コンテナーとアルゴリズムを記述します。STL はすばらしいものですが、すべての問題をすべてのケースで解決できる万能薬ではありません。ドメイン知識はあなたの最高の味方です。
独自のメモリ アロケータを作成することを検討しましたか? メモリ割り当て戦略が気に入らない場合は、常に STL 全体を切り替える必要はありません。すべてのコンテナーは、置換アロケーターを受け入れます。
コードのプロファイルを作成し、問題のある領域に小さな調整を加えたことを検討しましたか？私はそれがあなたが考えているものよりもはるかに痛みが少ないと思います。
Most of it depends on which container you are talking about, and how you are using it. vector usually has the smallest footprint, except at the moment you add an element that is beyond the current vector capacity. At that moment it it will allocate something like 1.5 x the current vectors capacity, move the elements (or in the worst case make a new copy which also allocates memory) and when that is done, delete the old vectors internals, If you know how many elements it is going to hold up front, vector with a use of reserve is your best bet.
The second smallest is list. It has the advantage that its not going to make a temporary copy of itself. After that set is your best bet is probably set. Some implementation have slist now, which is smaller. In these cases tt is pretty easy to make an allocator that packs the memory in pages. Stay away from memory hogs like unordered_*
On MSVC be sure to #define _SECURE_SCL=0 This takes out a lot of overhead used for secure programming checks (like buffer overruns, etc)
By far the most memory efficient containers are boost/intrusive These have extremely small footprints since they use the memory of the thing being contained. So instread of going to the heap for a small chunk of memory for a linked list or rb tree node, the node pointers are part of the object itself. Then the "container" is just one raw set of a few pointer to make a root node. I've used it quite a few times to get rid of footprint and allocation overhead.
パフォーマンスがアプリケーションにとって非常に重要であり、STLがそれに織り込まれている場合、オープンソースの実装（前述のSTL-Portなど）を見つけて自分でフォークし、必要に応じてパフォーマンスを向上させることは可能ですか？
一方では、これが滑りやすい坂道になり、STLライブラリのフォークに非標準の変更を加えて問題が発生することがわかります。ただし、アプリケーションのパフォーマンスの重要性は、これが発生するリスクを上回る可能性があります。
MSVC2003 のものを含め、ほとんどの STL 実装は、適切に実装された汎用ライブラリです。したがって、ある実装から別の実装への大幅なパフォーマンスの向上は見られません。
ただし、STL ライターが新しく作成しなかったデータについて知っているため、STL ライターよりも高速なアルゴリズム (またはコンテナー) を作成できる場合があります (一般的なコンテナーとアルゴリズムを作成していたため)。
結論として、アプリケーションのパフォーマンスを向上させたい場合は、よりパフォーマンスの高い STL を探すよりも、データに特別に適合する特殊なコンテナーを作成することをお勧めします。