Set COVERAGE_CORE: sysmon for faster tests on 3.12+

[hugovk]

Python 3.12 introduced sys.monitoring, that tools like coverage.py can use to improve performance.

It's not yet the default in coverage.py. To enable, we can set a COVERAGE_CORE=sysmon environment variable, that will switch to the faster mode when available, that is, in Python 3.12 and newer. Older versions will stick to the older method.

For example, on my machine:

test	command	result
No coverage	python3 -m pytest Tests	4269 passed, 224 skipped, 3 xfailed in 48.21s
Coverage: default core	python3 -m pytest --cov PIL --cov Tests Tests	4269 passed, 224 skipped, 3 xfailed in 58.15s
Coverage: sysmon core	COVERAGE_CORE=sysmon python3 -m pytest --cov PIL --cov Tests Tests	4269 passed, 224 skipped, 3 xfailed in 46.73s

Coverage time on CI, default core -> sysmon core:

CI job	before	after	speedup
AppVeyor 3.12	229.76s (0:03:49)	198.50s (0:03:18)	13.6%
macOS 3.13	68.55s (0:01:08)	62.33s (0:01:02)	9.1%
macOS 3.12	84.63s (0:01:24)	71.83s (0:01:11)	15.1%
Ubuntu 3.13	89.40s (0:01:29)	65.46s (0:01:05)	26.8%
Ubuntu 3.12	91.20s (0:01:31)	67.33s (0:01:07)	26.2%
Windows 3.13	156.69s (0:02:36)	134.59s (0:02:14)	14.1%
Windows 3.12	164.19s (0:02:44)	146.63s (0:02:26)	10.7%
Total	884.42 (0:14:41)	746.67 (0:12:23)	15.6%

---

I also added the env var to the Cygwin and MinGW workflows, even though they test Python <= 3.11. If they're upgraded to 3.12+ later, it'll take effect.

[radarhere]

It's not yet the default

Is the reason it's not yet the default, and why https://coverage.readthedocs.io/en/7.4.2/changes.html#version-7-4-0-2023-12-27 lists it as "experimental", just because branch coverage isn't faster? Or is there another reason?

[hugovk]

Yeah, I think it's both because of branch coverage, and because it's new and using new Python features, so feedback is requested.

If we find any problems, we can give feedback, and easily disable if necessary.

[radarhere]

I see that it is faster on AppVeyor, macOS and Ubuntu.

I find it harder to say conclusively that it is faster in Windows on GitHub Actions, but if it is theoretically, then ok.

[hugovk]

Here's three runs of Windows on GitHub Actions with main, 3 x 3.12, then 3 x 3.13:

= 3239 passed, 89 skipped, 3 xfailed, 1 xpassed, 4 warnings in 156.62s (0:02:36) =
= 3239 passed, 89 skipped, 3 xfailed, 1 xpassed, 4 warnings in 156.62s (0:02:36) =
= 3239 passed, 89 skipped, 3 xfailed, 1 xpassed, 4 warnings in 163.58s (0:02:43) =
= 3239 passed, 89 skipped, 3 xfailed, 1 xpassed, 4 warnings in 158.81s (0:02:38) =
= 3239 passed, 89 skipped, 3 xfailed, 1 xpassed, 4 warnings in 158.81s (0:02:38) =
= 3239 passed, 89 skipped, 3 xfailed, 1 xpassed, 4 warnings in 158.81s (0:02:38) =

https://github.com/hugovk/Pillow/actions/runs/7941332092/attempts/1
https://github.com/hugovk/Pillow/actions/runs/7941332092/attempts/2
https://github.com/hugovk/Pillow/actions/runs/7941332092/attempts/3

Then with the PR:

= 3239 passed, 89 skipped, 3 xfailed, 1 xpassed, 4 warnings in 139.70s (0:02:19) =
= 3239 passed, 89 skipped, 3 xfailed, 1 xpassed, 4 warnings in 147.11s (0:02:27) =
= 3239 passed, 89 skipped, 3 xfailed, 1 xpassed, 4 warnings in 150.77s (0:02:30) =
= 3239 passed, 89 skipped, 3 xfailed, 1 xpassed, 4 warnings in 135.98s (0:02:15) =
= 3239 passed, 89 skipped, 3 xfailed, 1 xpassed, 4 warnings in 138.57s (0:02:18) =
= 3239 passed, 89 skipped, 3 xfailed, 1 xpassed, 4 warnings in 137.47s (0:02:17) =

https://github.com/hugovk/Pillow/actions/runs/7986985726/attempts/1
https://github.com/hugovk/Pillow/actions/runs/7986985726/attempts/2
https://github.com/hugovk/Pillow/actions/runs/7986985726/attempts/3

[radarhere]

Despite passing on main a mere 11 hours ago, this has started failing in PyPy on Windows - https://github.com/python-pillow/Pillow/actions/runs/8016398970/job/21898259794