5

私はイベント ログ用の純粋な Python ファイル パーサーに取り組んでおり、そのサイズはキロバイトからギガバイトまでさまざまです。明示的な// .open()/呼び出しを単純なバッファのようなオブジェクトに抽象化するモジュールはありますか? これは の逆と考えることができます。次のようになると思います。.seek().read().close()StringIO

with FileBackedBuffer('/my/favorite/path', 'rb') as buf:
    header = buf[0:0x10]
    footer = buf[0x10000000:]

モジュールは私のmmap要件を満たすかもしれません。ただし、フィードバックをいただければ幸いです。

  1. モジュールが使用可能な RAM/スワップよりも大きなファイルを処理することが重要です。これがうまくできるかどうかはわかりmmapません。
  2. コンストラクタはmmapOS によって異なります。うまくクロスプラットフォームのコードを書こうとしていて、OS の仕様をいじりたくないので、これは私を躊躇させます。必要に応じてそうしますが、これにより、間違った場所を探している可能性があるという警告が発せられました。

そのようなタスクの正しいモジュールである場合mmap、これらの 2 つの点をどのように処理しますか? そうでない場合、適切なモジュールは何ですか?

4

1 に答える 1

5

mmap は、RAM/スワップより大きいファイルを簡単に処理できます。mmap ができないことは、アドレス空間よりも大きなファイルを処理することです。つまり、32 ビット システムでは、使用できるファイルの大きさが制限されています。

何が起こるかとmmapいうと、OS は選択した量のデータしかメモリに保持しませんが、プログラムはそれがすべてそこにあると考えます。ただし、データがRAMに収まらず、ランダムにジャンプしすぎると、スワップされます（最近使用していないファイルからページを破棄して、新しいページをロードするためのスペースを空けるため）、使用パターンには注意してください） .

basefilenoとを指定する必要がない場合lengthは、 のプラットフォーム固有の引数について心配する必要はないと思いますmmap。余分な引数について心配する必要がある場合は、Windows と Unix の違いを理解するか、それをユーザーに伝える必要があります。ライブラリがどうなるかはわかりませんが、ユーザーがオプションを微調整できるようにしながら、両方のプラットフォームで妥当なデフォルトを提供するとよいでしょう。また、クロスプラットフォームの場合は、Windows では選択の余地がないtagnameため、Unix のデフォルトをそのまま受け入れてください。とprotを気にするだけです。デフォルトはMAP_PRIVATEMAP_SHAREDMAP_SHARED、しかし、それが Windows の動作に最もよく一致するオプションであるかどうかはわかりませんが、デフォルトを受け入れることはおそらく問題ありません。

于 2012-12-24T05:31:03.840 に答える