[gustavpaul]

The MmapReader is not copying the requested byte range into the buf argument, so if ever the underlying file descriptor is closed (or the file truncated out of band) any subsequent slice access will throw SIGBUS, which is really unpleasant.

It also means the latency due to pagefaults is shifted from inside mmapReader.ReadRecord() (where it would be expected) to wherever in the application the bytes are first accessed, leading to spooky unpreditactable latency spikes in what are otherwise pure functions. That inevitably leads to wild arguments about how bad GC stalls are :-)

An apples to apples comparison should be copying the bytes from the mmap buffer and returning the resulting slice.

[loeg]

> so if ever the underlying file descriptor is closed

Nit: Mmap mapping lifetimes are not attached to the underlying fd. The file truncation and latency concerns are valid, though.

[dahfizz]

Being able to avoid an extra copy is actually a huge performance gain when you can safely do it. You shouldn't discount how useful mmap is just because its not useful in every scenario.

You shouldn't replace every single file access with mmap. But when it makes sense, mmap is a big performance win.

[dapperdrake]

It’s not accessible until it is in user space. (Virtual memory addresses mapped to physical RAM holding the data.)

Good point.