-
-
Notifications
You must be signed in to change notification settings - Fork 25.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CI Use sys.monitoring with coverage to speed-up Python >= 3.12 builds #29473
Conversation
@lesteve Have you experimented with https://github.com/plasma-umass/slipcover on this repo before? The author did run benchmarks with scikit-learn's testing: https://github.com/plasma-umass/slipcover?tab=readme-ov-file#performance I tried slipcover ~2 years ago and did see some improvements, but did not have time to purse it. |
I have heard of it recently but not run anything. It seems like it is missing a few integration that we need e.g. pytest-xdist support, XML results file. There are some discussions about merging SlipCover and coverage according to this slide of the PyConUS 2024 SlipCover talk. coveragepy with Python 3.12 can use Right now coveragepy does not really support branch coverage with The summary so far:
|
…nto statement-coverage
Could you please trigger another run for |
Note that in a67708e, Debian 32bit build took 35 minutes see build log. I think since we upgraded the Debian version for the 32bit CI (11->12) this build is a lot slower with quite some variability (the Debian 11->12 upgrade was done when getting rid of setuptools PR #29400). My hunch is that this is due to upgrading Python to 3.11 and that this might be related to coverage too but I am not 100% sure. For example on |
…nto statement-coverage
@lesteve this PR is still draft but I have the impression that it's a net improvement, no? |
It does speed up Python >= 3.12 builds. The minor downside is that we only use statement coverage which is less strict that branch coverage. With statement coverage the code below is fully covered. With branch coverage, the def func(x):
if x:
y = 'defined'
print(x)
func(True) |
I pushed 3 commits and honestly it seems to be worth it now, for example the current bottleneck debian32 takes 25 minutes instead of 50-60 minutes, I am marking this as ready for review. To reiterate the minor downside is that statement coverage is not as strict as branch coverage, see #29473 (comment). Here is a summary table:
Timings from build logs for first commit, second commit, third commit Comments:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the analysis~ I'm happening with using sys.monitoring
. LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM !
You need to regenerate the lock files though |
Note: I found out that one reason that makes the Hopefully there will be a scikit-image with Python 3.13 wheel soonish (there was a rc in October 2024 with Python 3.13 wheels).
I am having a quick look at pyamg Python 3.13 support in pyamg/pyamg#426. |
Follow-up of #29444 (comment), trying to see if using statement coverage makes a difference.
Reference run (same as
main
) build logRun with using statement coverage rather than branch coverage build log
Run with using statement coverage + COVERAGE_CORE=sysmon, this should make Python 3.12 builds faster build log
Run with using statement coverage + COVERAGE_CORE=sysmon, this should make Python 3.12 builds + updating openblas_pandas to Python 3.12 build log