Talk:Memory-mapped file

This article is rated C-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:

Computing This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles ??? This article has not yet received a rating on the project's importance scale.

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

The

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)[reply]

Hello fellow Wikipedians,

I have just added archive links to one external link on

• 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 {{

This message was posted before February 2018.

• 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.—

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.

• 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)[reply]