Update tests to use sysmon

[DarkaMaul]

Coverage introduced in Coverage.py 7.4.0 the support for sys.monitoring.

While it should not work well with the branch coverage used within warehouse, tests on our computers with @woodruffw showed a significant improvement:

Tests results

• With sysmon:
  • DarkaMaul : 26.7s
  • William: 29.36s
• Baseline:
  • DarkaMaul: 56.38s
  • William: 50.08s

The relevant issue in coverage is nedbat/coveragepy#1812

We would like to gather more feedback before eventually pushing this option forward.

NOTE: The other tracers are ctrace or pytrace

/cc @woodruffw

[woodruffw]

Thanks @DarkaMaul! I can confirm that this significantly speeds up the test suite in local runs for me.

I suspect coverage.py's branch performance regressions with sys.monitoring are pretty workload-dependent -- Warehouse is possibly just lucky enough to have a workload/layout that isn't causing significant issues relative to the baseline gains of using lightweight monitoring 🙂

[miketheman]

Definitely cool speedup!

Looks like this has some impact on how contexts are measured?
https://github.com/pypi/warehouse/actions/runs/10685632141/job/29619230896#step:5:236

/opt/warehouse/lib/python3.12/site-packages/coverage/html.py:123: CoverageWarning: No contexts were measured
  self.coverage._warn("No contexts were measured")

We measure contexts here:

warehouse/pyproject.toml

Line 3 in 6ce90e9

dynamic_context = "test_function"

This provides visual indicators in the HTML report to show which test functions are hitting a given line of code, making it easier to figure out which tests are calling what.

Is there anything on coverage.py tracking that issue, so we can leave ourselves a link to check in on it later on?

[DarkaMaul]

Is there anything on coverage.py tracking that issue, so we can leave ourselves a link to check in on it later on?

I think we should simply monitor coverage CHANGELOG to see when they are supported.

This PR can be either put on hold until coverage changes, or we can use the new setting for CI runs (with the possibility for interested developers to use it locally too).

[miketheman]

This PR can be either put on hold until coverage changes, or we can use the new setting for CI runs (with the possibility for interested developers to use it locally too).

I think we'd likely benefit from the speedups where possible.

Can you provide a hook to allow the developer to pass along a flag to revert the behavior? I don't think the current patch allows setting the envvar that passes to docker compose command in the Makefile, so giving the end user some pay of passing down that the COVERAGE_CORE should revert to to ctrace monitor would be good to have.