Thanks for the explanation! The ultimate speed is needed for server usage where, e.g. now, I have several TB free space and could allocate the entire space at start. For clients, where I use LMDB for replicated cache of data subsets, even the 3x perf drop is kind of tolerable given the absolute numbers. Could we have a flag to use the patch optionally? So that on a server where I could allocate 1+Tb and use hacks with WriteMap as we discussed previously, I could enjoy the speedup of WriteMap and the fact that the pointer addresses from MDB_RESERVE remain fixed over the lifetime of a process?
Another question: with this patch, do addresses of pointers remain the same after the map file size increases, or we must follow the LMDB rules as if there is no WriteMap flag is used? Does Windows reserve the entire virtual memory space, and the patch just affects the file size on a disk, or file growth with the patch is equivalent to remapping and pointer addresses become invalid every time? I am referring to this discussion
we had before.
P.S. I know your hate for Windows and am starting to share it given rich tools available on *nix, but for small non-hardcore-programmers teams doing exploratory number crunching the benefits of RDP & GUIs etc. outweigh the benefits *nix gives for high load production systems, so we use Windows as an internal server. LMDB is just a perfect off-heap data structure for many use cases.