Gregory Szorc <gregory.szorc@gmail.com> [Mon, 20 Jan 2020 23:51:25 -0800] rev 44118
hgdemandimport: apply lazy module loading to sys.meta_path finders
Python's `sys.meta_path` finders are the primary objects whose job it
is to find a module at import time. When `import` is called, Python
iterates objects in this list and calls `o.find_spec(...)` to find
a `ModuleSpec` (or None if the module couldn't be found by that
finder). If no meta path finder can find a module, import fails.
One of the default meta path finders is `PathFinder`. Its job is to
import modules from the filesystem and is probably the most important
importer. This finder looks at `sys.path` and `sys.path_hooks` to do
its job.
The `ModuleSpec` returned by `MetaPathImporter.find_spec()` has a
`loader` attribute, which defines the concrete module loader to use.
`sys.path_hooks` is a hook point for teaching `PathFinder` to
instantiate custom loader types.
Previously, we injected a custom `sys.path_hook` that told `PathFinder`
to wrap the default loaders with a loader that creates a module object
that is lazy.
This approach worked. But its main limitation was that it only applied
to the `PathFinder` meta path importer. There are other meta path
importers that are registered. And in the case of PyOxidizer loading
modules from memory, `PathFinder` doesn't come into play since
PyOxidizer's own meta path importer was handling all imports.
This commit changes our approach to lazy module loading by proxying
all meta path importers. Specifically, we overload the `find_spec()`
method to swap in a wrapped loader on the `ModuleSpec` before it
is returned. The end result of this is all meta path importers should
be lazy.
As much as I would have loved to utilize .__class__ manipulation to
achieve this, some meta path importers are implemented in C/Rust
in such a way that they cannot be monkeypatched. This is why we
use __getattribute__ to define a proxy.
Also, this change could theoretically open us up to regressions in
meta path importers whose loader is creating module objects which
can't be monkeypatched. But I'm not aware of any of these in the
wild. So I think we'll be safe.
According to hyperfine, this change yields a decent startup time win of
5-6ms:
```
Benchmark #1: ~/.pyenv/versions/3.6.10/bin/python ./hg version
Time (mean ± σ): 86.8 ms ± 0.5 ms [User: 78.0 ms, System: 8.7 ms]
Range (min … max): 86.0 ms … 89.1 ms 50 runs
Time (mean ± σ): 81.1 ms ± 2.7 ms [User: 74.5 ms, System: 6.5 ms]
Range (min … max): 77.8 ms … 90.5 ms 50 runs
Benchmark #2: ~/.pyenv/versions/3.7.6/bin/python ./hg version
Time (mean ± σ): 78.9 ms ± 0.6 ms [User: 70.2 ms, System: 8.7 ms]
Range (min … max): 78.1 ms … 81.2 ms 50 runs
Time (mean ± σ): 73.4 ms ± 0.6 ms [User: 65.3 ms, System: 8.0 ms]
Range (min … max): 72.4 ms … 75.7 ms 50 runs
Benchmark #3: ~/.pyenv/versions/3.8.1/bin/python ./hg version
Time (mean ± σ): 78.1 ms ± 0.6 ms [User: 70.2 ms, System: 7.9 ms]
Range (min … max): 77.4 ms … 80.9 ms 50 runs
Time (mean ± σ): 72.1 ms ± 0.4 ms [User: 64.4 ms, System: 7.6 ms]
Range (min … max): 71.4 ms … 74.1 ms 50 runs
```
Differential Revision: https://phab.mercurial-scm.org/D7954
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 20 Jan 2020 23:42:19 -0800] rev 44117
hgdemandimport: disable on Python 3.5
The demand importer functionality isn't working at all on Python 3.5.
I'm not sure what's wrong.
Since it isn't working, let's disable it completely.
```
$ HGRCPATH= hyperfine -w 1 -r 50 -- "~/.pyenv/versions/3.5.9/bin/python ./hg version" \
"HGDEMANDIMPORT=disable ~/.pyenv/versions/3.5.9/bin/python ./hg version"
Benchmark #1: ~/.pyenv/versions/3.5.9/bin/python ./hg version
Time (mean ± σ): 163.7 ms ± 2.2 ms [User: 148.5 ms, System: 15.7 ms]
Range (min … max): 161.0 ms … 170.2 ms 50 runs
Benchmark #2: HGDEMANDIMPORT=disable ~/.pyenv/versions/3.5.9/bin/python ./hg version
Time (mean ± σ): 164.3 ms ± 1.4 ms [User: 148.2 ms, System: 16.6 ms]
Range (min … max): 161.4 ms … 169.8 ms 50 runs
```
Differential Revision: https://phab.mercurial-scm.org/D7953
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 18 Jan 2020 11:13:01 -0800] rev 44116
py3: suppress unraisable exceptions in test-worker.t
Python 3.8 calls sys.unraisablehook when an unraisable
exception is encountered. The default behavior is to print a
warning.
test-worker.t was triggering this hook due to a race between
a newly forked process exiting and that process's
_os.register_at_fork handlers running. I was seeing the
stdlib's random module in the stack re-seeding itself. Although
there could be other after-fork handlers in the mix.
This commit defines sys.unraisablehook to effectively no-op.
This suppresses the warning and makes test output on Python 3.8
consistent with prior versions. test-worker.t now passes on
Python 3.8.
Differential Revision: https://phab.mercurial-scm.org/D7949
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Mon, 20 Jan 2020 18:28:46 -0500] rev 44115
rust: add a README
In particular to explain how to build any of the rust. It's neither
obvious, nor easy to find out, nor easy to determine if you did it
right without some documentation.
Differential Revision: https://phab.mercurial-scm.org/D7952
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Mon, 20 Jan 2020 17:44:03 -0500] rev 44114
rust: move hgcli's README out of the way
My understanding is that it's not meant to be used in the current
form.
Differential Revision: https://phab.mercurial-scm.org/D7951
Matt Harbison <matt_harbison@yahoo.com> [Sat, 18 Jan 2020 01:54:17 -0500] rev 44113
verify: avoid spurious integrity warnings in verbose mode (
issue6172)
The issue seems to revolve around renames in filtered commits, and only occurred
in verbose mode. The problem occurs in the `# check renames` stage, around line
577. Without using the unfiltered repo, this test would have printed:
$ hg verify -v
repository uses revlog format 1
checking changesets
checking manifests
crosschecking files in changesets and manifests
checking files
foo@25: checking rename of
71ec0570c325: filtered revision '25'
foobar@26: checking rename of
1b549296015b: filtered revision '26'
checked 28 changesets with 16 changes to 11 files
2 integrity errors encountered!
(first damaged changeset appears to be 25)
[1]
Differential Revision: https://phab.mercurial-scm.org/D7950
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 17 Jan 2020 22:31:47 -0800] rev 44112
py3: glob over exception in test-check-py3-compat.t
Python 3.6+ raise ModuleNotFoundError and older versions raise
ImportError. Glob over the exception differences.
For whatever reason, we were already doing this for one failure.
But not all occurrences of ModuleNotFoundError were changed.
Who knows.
This test should now pass on all Python versions (although I didn't
check Windows).
Differential Revision: https://phab.mercurial-scm.org/D7939
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 17 Jan 2020 22:24:27 -0800] rev 44111
py3: string normalization and I/O tweaks in test-lfs.t
The print was inserting b'' on Python 3. In addition, since we
weren't writing to the ui instance (which isn't readily available
in this function), output order could get mixed up.
We add some pycompat casts and a stdout flush to make the test
happy on all Python versions.
Differential Revision: https://phab.mercurial-scm.org/D7938
Matt Harbison <matt_harbison@yahoo.com> [Fri, 17 Jan 2020 21:27:53 -0500] rev 44110
help: minor copy editing to the `config.format` section
Differential Revision: https://phab.mercurial-scm.org/D7936
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 21 Nov 2019 17:27:44 +0100] rev 44109
changectx: mark parent of changesets as non filtered
If a node is not filtered, its parents cannot be filtered.
Differential Revision: https://phab.mercurial-scm.org/D7502