Add datafacade allocator backed by mmap

[TheMarex]

Issue

This is a first step towards #1947. We don't mmap the OSRM dataset directly but create a new file that basically stores the memory content as it is now. This is less effective both from a disk storage and startup time perspective, but should give us a good idea how the query performance using mmap without any optimizations.

Tasklist

• Try on biggest production dataset (bike?) and measure performance
• Investigate performance degradation under memory pressure.
• review
• adjust for comments
• cherry pick to release branch

Requirements / Relations

#1947

[TheMarex]

As a first prototype I tried to see what the general overhead is for using mmap instead of process internal memory and ran 50000 random queries on Bayern. Blue is internal memory red is mmap.
As you can see there is already a slight slowdown of just using mmap over internal memory even without memory pressure.
I ran two experiments once just running osrm-extract and osrm-contract and one that also ran osrm-partition to renumber the nodes in the graph using the partition information.

No renumbering

With renumbering

You can see that without memory pressure both perform about the same. The hope here is that renumbering will improve the locality.

[TheMarex]

We ran some experiments using the bicycle profile on North-America. To test the behavior under memory pressure, we first determined the minimal memory usage as 5.8G (first time serving queries completed without an OOM). Shows are the results for random queries which are generally the worst-case. The difference between 20% and 25% is quite large since we start to trash pages at a high rate due to the random access. For a 20% memory reduction, we would expect a slowdown of factor two in the worst case. All these results were obtained with 8 concurrent queries to test multi-thread page trashing.

[TheMarex]

If we use renumbering (running osrm-partition) we see a much better performance under memory pressure:

For completeness I also run tests using MLD to see how this approach fairs:

We can see that MLD is in general more resilient towards memory pressure than CH, but is overall slower.

[oxidase]

Looks good! I have two remarks to fix appveyor builds.

[oxidase]

file.string() would be better here as params.path is std::string.

[oxidase]

mode is deprecated, better to use params.flags = boost::iostreams::mapped_file::readwrite;

[TheMarex]

@oxidase can you check if this works for you? 🙇‍♂️

[oxidase]

@TheMarex works 👍, lgtm