2017-05-02 6 views
0

アイデアは、mallocとフリーコールを最小限に抑えるために一度にたくさんのメモリを割り当てるメモリマネージャを作成しています。私はこれを自分自身で2回書いてみましたが、メモリを最適化する問題。メモリマネージャの作成とメモリの最適化

ブロックが頻繁に空であるかどうかを確認するだけで、空であれば削除できます。しかし、あなたのブロックがそれぞれ100バイトで、最初に20バイトのメモリを割り当てたとしましょう。ブロックがまだ存在しないため新しい100バイトブロックが作成され、80バイトが割り当てられ、最初のブロックが満たされ、この最初のブロックがいっぱいであるために別の新しいブロックが作成され、次に2番目の割り当て(80バイト)が解放され、最初の20バイトのみが使用される2つのブロックが残ります。第2のブロックから第1のブロックに20バイトを移動させ、第2のブロックを削除することによって解放することができる。

  1. これを更新する必要があります、そのメモリへのすべてのポインタを意味するので、あなたの周りのメモリを移動することはできませんし、それが起こることのために、あなたは彼らを知っておく必要があります。

    これらは私がに走った問題がありますあなたがしていないアドレス。

  2. 100バイトは非常に小さなブロックサイズですが、非常に低解像度の(64,64)ARGBイメージをメモリに保存したいのですが?これは16KBのメモリを使用し、メモリマネージャをまったく書いていないよりも遅いかもしれないすべてのものを動かします。

それでもカスタムメモリマネージャを書く価値がありますか?

+0

バディシステムを見てください - https://en.wikipedia.org/wiki/Buddy_memory_allocation –

+3

解決する必要がある*実際のパフォーマンス上の問題はありますか?もしそうでなければ、これは早すぎる最適化だと言えます。 –

+5

一般的に使用されているmalloc/free実装のほとんどは、問題のドメインに関する深い知識を持つ才能豊かで経験豊富なプログラマーによって書かれており、実際の使用で発見された欠陥を考慮して時間をかけて研磨されています。つまり、可能な限り実装されているわけではありませんが、最初の試みではうまくいかない可能性があります。 – rici

答えて

0

それでもカスタムメモリマネージャを書く価値がありますか?

これは意見を求めていますが、私は事実上の答えを出そうとします。

ほとんどのオペレーティングシステムと言語サポートライブラリに付属するメモリアロケータは、一般に非常に高品質で、発生した問題の種類(断片化とパフォーマンス)やその他の問題に対処するように設計されています。彼らは汎用ののメモリアロケータと同程度に良好です。

アプリケーションに悪用可能な特定の割り当てパターンがある場合は、提供されたメモリアロケータよりも少し上手くいくことができます。それはまれですが、一般的に汎用メモリマネージャよりも単純なものを作ることで、一般的にその利点を生かすことができます。

あなたの周り

真のメモリを移動することはできません。現代のシステムでは、メモリを移動しようとすることさえしません。まず、断片化を避けようとします(通常、同様のサイズの割り当てをクラスタリングすることによって)。

古いシステム(仮想メモリマネージャーを持たないシステム)は、余分な間接層を持つメモリマネージャを使用することがありました。割り当てられたメモリへのポインタを返す代わりに、アロケータは "ハンドル"を返します。これは、メモリマネージャによって管理されているテーブルへのインデックスと同じくらいシンプルなものです。ユーザがメモリに実際にアクセスしたいとき、ユーザはメモリを「ロック」する。メモリマネージャは、ハンドルが余分なレベルの間接指示を与えたので、ロックされていないメモリ(例えば、断片化を解消する)を自由に移動することができた。

私は非常に低い解像度を保存したい場合はどのような

(64,64)ARGBのイメージに大きな割り当てがn個に分割することはないので、

ほとんどのメモリマネージャは、サイズの範囲を提供小さいブロック。大部分は、システムメモリ上の非常に大きな割り当てをシステムアロケータに割り当てます。システムアロケータは、プロセスアドレス空間が過度に断片化されていない限り、問題を一般的に解決できます。

関連する問題