問題タブ [memory-pool]

複数の std map<int,int> を使用することに興味があり、それらすべてに共通のメモリ プールから要素を割り当てるようにしたいと考えています。これまでに読んだことから、Boost pool_alloc などのカスタム アロケータを使用してこれを実現できます。

私の質問は、Boost pool_alloc のようなものを使用して要素自体の割り当てを管理しているにもかかわらず、std マップは、boost pool_alloc によって管理されない何らかの形のコンテナー オーバーヘッドとしてヒープ メモリを使用しますか? std マップ自体の使用に関して、要素へのポインターの行に沿って何かを考えていますか?

talloc のようなプールを提供し、特に C++ の機能とうまく連携するように設計されたメモリ割り当てライブラリはありますか?

特に：

1. プールの大きさを事前に予測できます。誤ってオーバーフローする危険はありません。

2. プールにオブジェクトを割り当てた場合、プール全体の割り当てが解除されるまで、そのストレージを再利用する必要はありません。(そのため、オブジェクトは単純にプールに順番に割り当てることができ、さまざまな型のアラインメントを考慮してパディングを挿入する以外に無駄はありません。)

3. さまざまなサイズとアライメントのオブジェクトを 1 つのプールに割り当てる機能が必要です。

4. 標準ライブラリ コンテナーの要素をプールに格納する必要があります。(s の特定のケースではstd::vector、構築時に内部バッファーの容量を設定し、それ以上ベクトルを大きくしようとはしません。)

私がしたくないことは次のとおりです。

1. デストラクタを再発明します。
2. 例外を再発明します。
3. 標準ライブラリ コンテナーを再発明します。
4. を使用しvoid *ます。

私は現在、カプセル化の標準的な手法として不透明なポインターを使用していますが、OpenGL API を見ると、id 番号を使用する方が良い選択である可能性があると思います。ベテランの C プログラマーからのアドバイスをお願いします (この言語を積極的に使用してから 2 年ほどしか経っていません)。

確認または修正したい私の最初の考えは次のとおりです。

ID 番号の考えられる利点:

• ID番号を使用する場合、実装でオブジェクト/メモリプールを使用するのはかなり簡単です

• ID 番号はシステム メモリにマップする必要はありません (GL の場合はグラフィックス メモリを参照できます)。

ID 番号の考えられる短所:

• 実装が少し複雑になります

共有ライブラリを使用する状況を考慮した同様の質問があります: 不透明なオブジェクトに整数 ID またはポインターを使用する必要がありますか? 私の質問は共有ライブラリに関するものではなく、ユーザー コードから実装の詳細を隠す一般的なケースに関するものです。

MyObjectHandle を typedef して、ライブラリが ID 番号と不透明なポインターを切り替えることができると思います。

問題は 、不透明なポインターと C プログラミング言語を使用した ID 番号の長所と短所は何ですか?

ネットワークから大量のデータを継続的に読み取るアプリケーションがあります。私たちは GC (gen0 コレクションの累積的な効果でさえも。調査結果をサポートするために ETW 収集を使用しました) を最大のボトルネックとして特定したため、コレクションが開始されないようにメモリ プールを実行しようとしました。

巨大なバイト配列を事前に割り当てて、割り当てなしでネットワークから継続的に読み取ることができます。char 配列でも同じことを実行できます (Encoding クラスでの変換中の割り当てを回避するため)。ただし、基本型 (int) に変換する方法はないようです。 、decimal ...) ホイールを再発明することなく (TryParse メソッドで BCL が行うことを再実装することを意味します)、またはガベージを作成せずに (char[] を破棄される文字列に変換します)。

だからここに私の質問があります：

• どうにかして char 配列を文字列に挿入したり、文字列に再利用可能なメモリ プールからメモリを割り当てさせたりすることはできますか? 文字列の反映された内部を調べていましたが、不可能な作業のようですが、提案を歓迎します

また

• いくつかの標準変換関数を利用して、char[] (または System.String 形式ではない他のテキスト) から基本型に変換することは可能ですか? 繰り返しますが、System.Number のリフレクション コードを調べていました。アンダーカバー関数は char * を使用しているように見えるため、リフレクション経由でそれらを呼び出すことができます。ただし、DateTime 変換では引き続き文字列が使用されます。

どんな提案も歓迎します。

データベース バッファ プール (メモリ プール) の実装では、メモリ内のページで構成されるバッファがあります。

ページにはさまざまなサイズがあります (すべて 512kb の整数倍)。

エビクション ポリシーが LRU (最近使用されていない) であるとしますが、エビクトしようとしているページのサイズが、置き換える必要のあるサイズよりも小さいとします。LRU にも従いたい場合は、収まるのに必要な数の LRU ページをエビクトする必要があります。私の新しいページ。

n最近使用したページを削除する必要があるとします。ただし、これらのページは、バッファ/メモリ プール内で必ずしも連続しているわけではありません。

私が考えた簡単な方法は、これらのnページを結合することです。つまり、バッファー プールを適切に並べ替える必要があります。

最も簡単な方法は、バッファー全体をコピーして永続バッファーを上書きし、データ型を適切に更新することです。ただし、これは、この操作のためにバッファ全体をコピーするのに十分な RAM があることを前提としています。バッファ全体をコピーする必要がない賢いアプローチはありますか?

ありがとう

new / malloc が使用されるたびに、OS はページ サイズに合わせて新しい (または再利用する) ヒープ メモリ セグメントを作成し、それを呼び出しプロセスに返します。これらの割り当てはすべて、プロセスの仮想メモリを構成します。32 ビット コンピューティングでは、どのプロセスも 4 GB までしかスケーリングできません。ヒープ割り当てが高いほど、プロセス メモリの増加率が高くなります。多くのメモリ管理/メモリ プールが利用可能ですが、これらのユーティリティはすべて、ヒープを作成して効率的に再利用することになります。

一方、mmap (メモリ マッピング) は、ファイルをメモリ ストリームとして視覚化する機能を提供し、プログラムがファイルに対して直接ポインタ操作を使用できるようにします。しかしここでも、mmap は実際にはプロセス空間内のアドレスの範囲を割り当てています。したがって、サイズが 3GB の 3GB ファイルを mmap し、プロセスの pmap を取得すると、プロセスによって消費される合計メモリが >= 3GB であることがわかります。

私の質問は、[ファイルを mmap するのと同じように] ファイル ベースのメモリ プールを持つことは可能ですが、プロセス メモリ空間を構成するものではありません。ファイルに支えられたメモリDBのようなものを視覚化します。これは、読み取り/書き込みが非常に高速で、ポインター操作をサポートします[つまり、レコードへのポインターを取得し、new / mallocを使用しているかのように何でも保存します]。プロセスの仮想 4GB 制限に触れることなく、ディスク上で拡張できます。

出来ますか ？もしそうなら、私が仕事を始めるためのいくつかの指針は何ですか. 既製のソリューションやリンクを求めているのではなく、それを実現する方法を概念的に理解することを求めています。

*p=malloc(1000)の場合、メモリpを200と300のブロックに分割し、ブロックのアドレスを取得して使用したい。これを行う簡単な方法はありますか？