Talk:Memory-mapped file

Is there _I/O_ performance benefit of mmaped files?

The pages gives the impression that it is faster to access mmaped files compared to I/O syscalls. However, the it is a faulty conclusion as it's based on comparison of memory access to actual I/O. There is no I/O involved in accessing a cached memory page of mmapped file. The same "benefit" may be achieved by using locally-buffered "I/O" e.g. like fwrite() does. —Preceding unsigned comment added by 129.97.169.227 (talk) 20:07, 23 March 2011 (UTC)

Drawbacks: Page faults in mmapping vs. in syscalls

The sentence "The memory mapped approach has its cost in page faults - when a piece of data isn't actually loaded by the operating system" is unlikely - both ways have a chance to request data not in the cache. Yes, when doing random reads the memory-mapped access is usually chosen (because no need to call seek()), but such access is slow because of the random reads, not because of memory-mapping. Also OS provides both fadvise() (for syscall access) and madvise() (for mmapping). Therefore the cache-miss probability is the same.

I propose to delete the paragraph. --Alvin-cs ✉ 13:25, 11 September 2009 (UTC)

The explanation given in the article indeed doesn't seem to make a lot of sense, but it's certainly true that mmap is not always faster than read. Even when accessing a cached mmap'ed file, the process would still be generating minor page faults — for pages that do exist in the page cache, but are not yet mapped into the process's VM space. Creating these mappings involves among other things modifying page tables and invalidating the CPU's TLB (translation lookaside buffer, basically the CPU's MMU cache for VM mappings). These operations come at a cost that can exceed the cost of buffer copies. In small microbenchmarks you usually don't feel the overhead, but larger apps take a bigger hit because they rely more on the TLB.

I didn't spend much time looking for references, but here's one that explains the gist of it: [1] -- intgr [talk] 18:32, 11 September 2009 (UTC)

Minor page faults, a good one, Sir. If the TLB does not cache missing mappings (likely, since they are either fatal or result in re-mapping) then it does not require invalidation. But it looks like syscall-style penalty anyway. -- Updated the article. Removed the not-even-in-cached case.--Alvin-cs ✉ 00:46, 13 September 2009 (UTC)

History

There should be a history section. What is the first system with memory mapped files? 4.1cBSD? 91.154.87.201 (talk) 15:34, 23 March 2012 (UTC)

MMF Advantages

The whole gist of this page is wrong. The implication here is that MMFs are used primarily for performance reasons. This is largely not true. With respect to this claim, I will make the following general assertion, and then move on. While the buffering systems built into hardware and OSs are designed to make sequential I/O faster, MMFs are designed to make random accesses faster. If you think about what gets moved into memory, this will become obvious.

The real advantage of MMFs is elegance and conciseness of code. For example, if you wanted to have a hash table, and have it in memory and yet also on disk (persistent), instead of writing a lot of code to manage both disk and memory, and then keep them in synch, you could use a MMF and safely just pretend the entire hash table was in memory, whether it really is or not. The CPU's MMU will worry about keeping the two in synch, and will make resident in memory only what has most recently been used by your hash routine.

I once wrote a garbage collection routine which got rid of deleted rows in a database table, and then sort them on a key. Using a MMF I was able to remove deleted records by memmov()-ing undeleted rows (based on a bit flag), overwriting that memory, and then just call qsort() to sort the file based on a struct.key. The entire operation took less than 10 lines of C code.

In summary, it's misleading to discuss MMFs in the context of efficiency, although for random accesses they can perform better. Ignoring interprocess communication, the real advantage is the ability to treat a file as a big chunk of memory.

--Solidpoint (talk) 09:26, 3 December 2012 (UTC)

Platform Support

The golang programming language supports memory mapped files with the mmap package: https://godoc.org/golang.org/x/exp/mmap

This is used in the somewhat prominent boltdb key/value store: https://github.com/boltdb/bolt

I think this makes a decent case for including go on the list of platforms with support for memory mapped files. — Preceding unsigned comment added by 2607:F720:F00:4032:384C:BC93:789:4A88 (talk) 02:09, 25 February 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to one external link on Memory-mapped file. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• Added archive http://web.archive.org/web/20070209012757/http://www.ecst.csuchico.edu:80/~beej/guide/ipc/mmap.html to http://www.ecst.csuchico.edu/~beej/guide/ipc/mmap.html

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 14:22, 21 March 2016 (UTC)

External links modified (January 2018)

Hello fellow Wikipedians,

I have just modified 2 external links on Memory-mapped file. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20090423231611/http://www.apple.com/macosx/technology/unix.html to https://www.apple.com/macosx/technology/unix.html
• Added archive https://web.archive.org/web/20100419135457/http://winterdom.com/dev/net to http://winterdom.com/dev/net

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 15:09, 25 January 2018 (UTC)