タグ付けされた質問 「mmap」

POSIX環境では、少なくとも2つの方法でファイルにアクセスできます。標準のシステムコールがありますopen()、read()、write()、と友人は、しかし、使用するオプションもありますmmap()仮想メモリにファイルをマップするためには。 どちらを使用するのが望ましいですか？2つのインターフェースを含めることのメリットは何ですか？

276 c  file-io  posix  mmap 

サイズが100GB以上になる可能性のあるファイルを処理するプログラムに取り組んでいます。ファイルには、可変長レコードのセットが含まれています。私は最初の実装を稼働させており、特に入力ファイルが何度もスキャンされるので、特にI / Oをより効率的に行うことで、パフォーマンスの改善に向けています。 mmap()C ++のfstreamライブラリを介したブロックの使用と読み取りの経験則はありますか？私がしたいことは、ディスクから大きなブロックをバッファーに読み込み、バッファーから完全なレコードを処理して、さらに読み込むことです。 'dブロックはページサイズの境界（私の理解）にある必要があり、レコードがページ境界を越えて潜在的に好きになるmmap()可能性があるため、コードは非常に複雑になるmmap可能性があります。ではfstream、私たちが読んブロックに限定していないことからS、私はページ上の嘘は、境界をサイズのことを、レコードの開始をシークして、もう一度読み始めることができます。 最初に完全な実装を実際に作成せずに、これらの2つのオプションをどのように決定できますか？経験則（例：mmap()2倍高速）または簡単なテスト？

185 c++  file-io  fstream  mmap 

これで頭を壁に打ちつけています。 私のプロジェクトではmmap、マッピング（/proc/self/maps）を使用してメモリを割り当てているときに、読み取り可能なメモリのみを要求したにもかかわらず、それが読み取り可能で実行可能な領域であることを示しています。 strace（見栄えは良かった）やその他のデバッグを調べたところ、この奇妙な問題を回避していると思われる唯一のこと、つまりプロジェクトからアセンブリファイルを削除し、純粋なCのみを残すことを特定できました（何ですか？）。 だからここに私の奇妙な例が​​あります、私はUbunbtu 19.04とデフォルトのgccに取り組んでいます。 ターゲットの実行可能ファイルをASMファイル（空）でコンパイルするとmmap、読み取り可能で実行可能な領域が返されます。ビルドしないと、正しく動作します。/proc/self/maps私の例に組み込んだ出力を参照してください。 example.c #include <stdio.h> #include <string.h> #include <sys/mman.h> int main() { void* p; p = mmap(NULL, 8192,PROT_READ,MAP_ANONYMOUS|MAP_PRIVATE,-1,0); { FILE *f; char line[512], s_search[17]; snprintf(s_search,16,"%lx",(long)p); f = fopen("/proc/self/maps","r"); while (fgets(line,512,f)) { if (strstr(line,s_search)) fputs(line,stderr); } fclose(f); } return 0; } example.s：空のファイルです！ アウトプット ASM付属バージョン VirtualBox:~/mechanics/build$ gcc example.c …

94 c  linux  assembly  mmap