Proposal: Extend MemoryMappedFile API

[msedi]

Currently, the MemoryMappedFile API is great but doesn't expose some properties that are available in the WinAPI.
While I understand that also other platforms are currently supported it would be nice to find a common way to extend the API.
The suggestions are:

Enable FileOptions
Currently when using MemoryMappedFile.CreateFromFile no FileOptions property is allowed to be handed over to this method. Some of the enums in FileOptions may be useless, some not (e.g. FileOptions.DeleteOnClose). Currently there exists a
MemoryMappedFileOptions that could be extended so that the options can be abstracted rather than using FileOptions directly.

Large Page Support
It is not possible to use Large_Pages, from the WinAPI I can see that it is only possible in system paging files and not in file backed paging file, but I don't have too much experience on that.

More control over memory
It's currently not possible to invalidate memory (DiscardVirtualMemory) so that the memory manager can ignore these areas and will not write it back to the paging file. Additionally it is currently not possible to mark pages as "not in use" (VirtualUnlock) so that the memory manager is able to page them earlier. Also it is not possible to prefetch pages (PrefetchVirtualMemory).

Better backing file control
It seems that some options but I do not have good benchmarks allow for better performance. SetFileValidData and Sparse File Support are the keywords. My current tests showed that using sparse files, had an improvement from 150s to 100s.

Flush areas
FlushViewOfFile allows more control of which areas are flushed and should be available in MemoryMappedViewAccessor.Flush.

Do not flush the view on disposal
Currently the filestream is flushed when disposing the memory mapped structures, which are causing enormous performance drop when the file is opened with FileOptions.DeleteOnClose. Since the file is deleted on disposal it doesn't really make sense to flush it to the backing file.

It would bew good if the API methods are abstracted somehow and the true API is not exposed.
It is of course welcome to discuss this proposal.

[jozkee]

This should be tracked in an API proposal.

[msedi]

Thanks for hinting on this. I already had a discussion with one single topic of this proposal with @stephentoub. I will move this to an API proposal. Thanks.