mmap: populate the mapping by default Without pre-population, accessing all data through a mmap can result in many pagefault, reducing performance significantly. If the mmap is prepopulated, the performance can no longer get slower than a full read. (See benchmark number below) In some cases were very few data is read, prepopulating can be overkill and slower than populating on access (through page fault). So that behavior can be controlled when the caller can pre-determine the best behavior. (See benchmark number below) In addition, testing with populating in a secondary thread yield great result combining the best of each approach. This might be implemented in later changesets. In all cases, using mmap has a great effect on memory usage when many processes run in parallel on the same machine. ### Benchmarks # What did I run A couple of month back I ran a large benchmark campaign to assess the impact of various approach for using mmap with the revlog (and other files), it highlighted a few benchmarks that capture the impact of the changes well. So to validate this change I checked the following: - log command displaying various revisions (read the changelog index) - log command displaying the patch of listed revisions (read the changelog index, the manifest index and a few files indexes) - unbundling a few revisions (read and write changelog, manifest and few files indexes, and walk the graph to update some cache) - pushing a few revisions (read and write changelog, manifest and few files indexes, walk the graph to update some cache, performs various accesses locally and remotely during discovery) Benchmarks were run using the default module policy (c+py) and the rust one. No significant difference were found between the two implementation, so we will present result using the default policy (unless otherwise specified). I ran them on a few repositories : - mercurial: a "public changeset only" copy of mercurial from 2018-08-01 using zstd compression and sparse-revlog - pypy: a copy of pypy from 2018-08-01 using zstd compression and sparse-revlog - netbeans: a copy of netbeans from 2018-08-01 using zstd compression and sparse-revlog - mozilla-try: a copy of mozilla-try from 2019-02-18 using zstd compression and sparse-revlog - mozilla-try persistent-nodemap: Same as the above but with a persistent nodemap. Used for the log --patch benchmark only # Results For the smaller repositories (mercurial, pypy), the impact of mmap is almost imperceptible, other cost dominating the operation. The impact of prepopulating is undiscernible in the benchmark we ran. For larger repositories the benchmark support explanation given above: On netbeans, the log can be about 1% faster without repopulation (for a difference < 100ms) but unbundle becomes a bit slower, even when small. ### data-env-vars.name = netbeans-2018-08-01-zstd-sparse-revlog # benchmark.name = hg.command.unbundle # benchmark.variants.issue6528 = disabled # benchmark.variants.reuse-external-delta-parent = yes # benchmark.variants.revs = any-1-extra-rev # benchmark.variants.source = unbundle # benchmark.variants.verbosity = quiet with-populate: 0.240157 no-populate: 0.265087 (+10.38%, +0.02) # benchmark.variants.revs = any-100-extra-rev with-populate: 1.459518 no-populate: 1.481290 (+1.49%, +0.02) ## benchmark.name = hg.command.push # benchmark.variants.explicit-rev = none # benchmark.variants.issue6528 = disabled # benchmark.variants.protocol = ssh # benchmark.variants.reuse-external-delta-parent = yes # benchmark.variants.revs = any-1-extra-rev with-populate: 0.771919 no-populate: 0.792025 (+2.60%, +0.02) # benchmark.variants.revs = any-100-extra-rev with-populate: 1.459518 no-populate: 1.481290 (+1.49%, +0.02) For mozilla-try, the "slow down" from pre-populate for small `hg log` is more visible, but still small in absolute time. (using rust value for the persistent nodemap value to be relevant). ### data-env-vars.name = mozilla-try-2019-02-18-ds2-pnm # benchmark.name = hg.command.log # bin-env-vars.hg.flavor = rust # benchmark.variants.patch = yes # benchmark.variants.limit-rev = 1 with-populate: 0.237813 no-populate: 0.229452 (-3.52%, -0.01) # benchmark.variants.limit-rev = 10 # benchmark.variants.patch = yes with-populate: 1.213578 no-populate: 1.205189 ### data-env-vars.name = mozilla-try-2019-02-18-zstd-sparse-revlog # benchmark.variants.limit-rev = 1000 # benchmark.variants.patch = no # benchmark.variants.rev = tip with-populate: 0.198607 no-populate: 0.195038 (-1.80%, -0.00) However pre-populating provide a significant boost on more complex operations like unbundle or push: ### data-env-vars.name = mozilla-try-2019-02-18-zstd-sparse-revlog # benchmark.name = hg.command.push # benchmark.variants.explicit-rev = none # benchmark.variants.issue6528 = disabled # benchmark.variants.protocol = ssh # benchmark.variants.reuse-external-delta-parent = yes # benchmark.variants.revs = any-1-extra-rev with-populate: 4.798632 no-populate: 4.953295 (+3.22%, +0.15) # benchmark.variants.revs = any-100-extra-rev with-populate: 4.903618 no-populate: 5.014963 (+2.27%, +0.11) ## benchmark.name = hg.command.unbundle # benchmark.variants.revs = any-1-extra-rev with-populate: 1.423411 no-populate: 1.585365 (+11.38%, +0.16) # benchmark.variants.revs = any-100-extra-rev with-populate: 1.537909 no-populate: 1.688489 (+9.79%, +0.15)

typing: add a trivial type hint to `mercurial/vfs.py` Since hg 3dbc7b1ecaba, pytype stopped seeing the return value of `rmtree` as `None`, and substituted `Any`.

typing: add a few trivial type hints to `mercurial/templater.py` Since hg 3dbc7b1ecaba, pytype started inferring that the second value in the tuple is `BinaryIO`, but still hasn't been able to figure out the rest of `open_template()`. We can be more precise.

typing: add a few type hints to `mercurial/revlog.py` Somewhere between hg 3dbc7b1ecaba and hg 8e3f6b5bf720, pytype stopped being able to infer the type for `_docket_file` and `compress()`. Lock those types in before they get lost.

typing: add a trivial type hint to `mercurial/posix.py` to avoid an @overload Since hg 3dbc7b1ecaba, pytype added an `@overload` for this function, without a type on the parameter. That's wrong, and undermines the hints on the non-trivial functions.

typing: add some trivial type hints to `mercurial/match.py` These were new methods since hg 3dbc7b1ecaba, but surprisingly pytype couldn't figure them out.

typing: add a type hint to `mercurial/hg.py` Somewhere between hg 3dbc7b1ecaba and hg 8e3f6b5bf720, the first value of the tuple changed from bytes to str. Let's lock this in, so that pytype flags it if someone mistakenly adds a tuple with bytes somewhere.

typing: restore `encoding.encoding` and `encoding.encodingmode` to bytes Somewhere between hg 3dbc7b1ecaba and hg 8e3f6b5bf720, pytype determined the signature of these fields changed from `bytes` to `Any`. Not sure why- the type of `environ` then and now is: `Union[WindowsEnviron, Dict[bytes, bytes], os._Environ[bytes]]` That said, PyCharm wasn't able to figure out the type of `environ`, and the `WindowsEnviron` class extends `MutableMapping` without specifying bytes for the key and value types in py3.9. But that's not changed in my setup, so I can't explain it.

typing: add some trivial type hints to `mercurial/bundlecaches.py` The function is meant for extensions, but it wasn't obvious what was expected without looking through the code. Also, pytype couldn't figure it out either.

typing: add some type hints for bundle2 capabilities Somewhere between hg 3dbc7b1ecaba and hg 8e3f6b5bf720, pytype determined the signature of `bundle20.capabilities` changed from `Dict[bytes, Tuple[bytes]]` to `Dict[bytes, Union[List[bytes], Tuple[bytes]]]`. First, I did try to simply be explicit about the previously inferred type, but it does seem to mix and match list/tuple now (e.g. in `writenewbundle()`). I tried changing the new list usage to tuple, but a couple of things complained, (and I think lists of one item are a little more clear to read anyway). So then I typed the dict value as `Sequence[bytes]`, which worked fine. But there's also a module level `capabilities` field, and when that's typed, pytype complains about `Sequence[bytes]` lacking `__add__`[1]. So I gave up, and just assigned it the type it wanted, with an alias. If somebody feels motivated to make the type consistent, it's simple enough to change the alias. The mutable default value to the constructor was removed to appease PyCharm's type checking on the field. (I didn't bother running the code through pytype prior to changing it, because we've previously made an effort to remove this pattern anyway.) I'm not sure why `getrepocaps()` has a default value for `role` that apparently raises an exception. It's just flagged for now so this series can land without risking additional problems. [1] https://foss.heptapod.net/mercurial/mercurial-devel/-/jobs/2466903