誰かが次の3つが速度の点でどれほどよく比較されるか知っていますか?
共有メモリ
tmpfs(/ dev / shm)
mmap(/ dev / shm)
ありがとう!
tmpfs
ここについて読んでください。tmpfs
以下はその記事からのコピーで、特に共有メモリとの関係を説明しています。
1) There is always a kernel internal mount which you will not see at
all. This is used for shared anonymous mappings and SYSV shared
memory.
This mount does not depend on CONFIG_TMPFS. If CONFIG_TMPFS is not
set the user visible part of tmpfs is not build, but the internal
mechanisms are always present.
2) glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for
POSIX shared memory (shm_open, shm_unlink). Adding the following
line to /etc/fstab should take care of this:
tmpfs /dev/shm tmpfs defaults 0 0
Remember to create the directory that you intend to mount tmpfs on
if necessary (/dev/shm is automagically created if you use devfs).
This mount is _not_ needed for SYSV shared memory. The internal
mount is used for that. (In the 2.3 kernel versions it was
necessary to mount the predecessor of tmpfs (shm fs) to use SYSV
shared memory)
したがって、実際に POSIX 共有メモリ (以前も使用していました) を使用すると、アプリケーション間でデータを共有するために使用される にglibc
ファイルが作成されます。/dev/shm
返されるファイル記述子はそのファイルを参照します。これを渡してmmap
、「実際の」ファイルと同様に、そのファイルをメモリにマップするように指示できます。したがって、リストした手法は補完的です。彼らは競争していません。Tmpfs
の実装手法としてインメモリ ファイルを提供する単なるファイル システムですglibc
。
例として、現在そのような共有メモリ オブジェクトを登録している私のボックスで実行中のプロセスがあります。
# pwd
/dev/shm
# ls -lh
insgesamt 76K
-r-------- 1 js js 65M 24. Mai 16:37 pulse-shm-1802989683
#
"場合によります。" 一般に、それらはすべてメモリ内にあり、システムの実装に依存しているため、ほとんどの用途ではパフォーマンスは無視でき、プラットフォーム固有です。パフォーマンスが本当に重要な場合は、プロファイルを作成して要件を決定する必要があります。これらのメソッドのいずれかを別のメソッドに置き換えるのは非常に簡単です。
とは言っても、ファイル操作が含まれていないため、共有メモリは最も集中的ではありません (ただし、非常に実装に依存します)。開閉 (マップ/マップ解除) を何度も繰り返し行う必要がある場合は、かなりのオーバーヘッドになる可能性があります。
乾杯!
ショーン
「共有メモリ」とは、System V 共有メモリのことですよね?
これを使用すると、Linux mmap は非表示の tmpfs になると思うので、実質的には tmpfs を mmap するのと同じです。
tmpfs でファイル I/O を実行すると、ペナルティが発生します...ほとんどの場合 (32 ビット プロセスで 4G を超えるなど、意味のある特殊なケースがあります)
tmpfs が最も遅いです。共有メモリと mmap は同じ速度です。