On Tue, Dec 18, 2018 at 01:13:32AM +0000, Cyroxin via Digitalmars-d-announce wrote: [...] > I would assume that there is much value in having a mapping that can > be reused instead of having to remap files to the memory when a need > arises to change source. While I cannot comment on the general > efficiency between a mapped file and a circular buffer without > benchmarks, this may be of use: > https://en.wikipedia.org/wiki/Memory-mapped_file#Drawbacks
You have a good point that unmapping and remapping would be necessary for large files in a 32-bit arch. > An interesting fact I found out was that std.mmfile keeps a reference > of the memory file handle, instead of relying on the system's handle > closure after unmap. There seems to be quite a lot of globals, which > is odd as Elembuf only has one. I'm not sure I understand what you mean by "globals"; AFAICT MmFile just has a bunch of member variables, most of which are only important on the initial mapping and later unmapping. Once you get a T[] out of MmFile, there's little reason to use the MmFile object directly anymore until you're done with the mapping. > In std.mmfile OpSlice returns a void[] instead of a T[], making it > difficult to work with as it requires a cast, there would also be a > need to do costly conversions should "T.sizeof != void.sizeof" be > true. Are you sure? Casting void[] to T[] only needs to be done once, and the only cost is recomputing .length. (Casting an array does *not* make a copy of the elements or anything of that sort, btw.) Once you have a T[], it's pointless to call Mmfile.opSlice again; just slice the T[] directly. > However, from purely a code perspective Elembuf attempts to have > minimal runtime arguments and variables, with heavy reliance on > compile time arguments. It also uses a newer system call for Linux > (Glibc) that is currently not in druntime, the reason for this system > call is that it allows for faster buffer construction. Read more about > it here: https://dvdhrm.wordpress.com/2014/06/10/memfd_create2/ Hmm. Isn't that orthogonal to mmap(), though? You could just map a memfd descriptor using mmap() to achieve essentially equivalent functionality. Am I missing something obvious? T -- Which is worse: ignorance or apathy? Who knows? Who cares? -- Erich Schubert
