mmap file performance

[Patrick Schluter]

On Monday, 15 April 2024 at 16:13:41 UTC, Andy Valencia wrote:
> On Monday, 15 April 2024 at 08:05:25 UTC, Patrick Schluter 
> wrote:
>> The setup of a memory mapped file is relatively costly. For 
>> smaller files it is a net loss and read/write beats it hands 
>> down.
>
> Interestingly, this performance deficit is present even when 
> run against the largest conveniently available file on my 
> system--libQt6WebEngineCore.so.6.4.2 at 148 megs.  But since 
> this reproduces in its C counterpart, it is not at all a 
> reflection of D.
>
> As you say, truly random access might play to mmap's strengths.

Indeed, my statement concerning file size is misleading. It's the 
amount of operations done on the file that is important. For 
bigger files it is normal to have more operations.
I have measurement for our system (Linux servers) where we have 
big index files which represent a ternary tree that are generally 
memory mapped. These files are several hundreds of megabytes big 
and the access is almost random. These files still grow but the 
growing parts are not memory mapped but accessed with pread() and 
pwrite() calls. Accesses via pread() take exactly twice the time 
from memory copy for reads of exactly 64 bytes (size of the 
record).

>
> My real point is that, whichever API I use, coding in D was far 
> less tedious; I like the resulting code, and it showed no 
> meaningful performance cost.