Announcing Elembuf

[H. S. Teoh]

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