Repository navigation
TST: add a lot of missing slow markers - #31420
Conversation
As discussed in issue 31419, the goal is to mark tests with a duration
above 0.5-1 sec. on commonly used CPUs (say x86-64 CPU of a few years old)
as `slow` unless there's a good reason to keep it in the default
set that gets executed by `numpy.test()` rather than `numpy.test('full')`.
Slowest tests are compile tests for `cython` and `f2py`, tests for reference
cycles and the like, multi-threaded tests, custom memory allocators,
and highly parametrized tests that are relatively slow (often dealing with
object arrays or other inherently slower features).
With this change, we move about 700 out of 47,000 tests to the 'full' mode,
resulting in a speedup of the default test() invocation of roughly 50%.
Closes numpygh-31419
seberg
left a comment
seberg
left a comment
There was a problem hiding this comment.
Thanks, LGTM. We probably also have some highly parametrized tests that could be marked slow (IIRC --durations reports individual tests, if you have a gigantic parametrization it doesn't notice).
These look good though, most are compilation tests and it looks like the f2py changes are just that the existing pattern wasn't used consistently anyway.
(And I agree to keep the cython ones, they compile, but not for each individual test in practice.)
|
Hmmmm, one small caveat is that I think with this we don't have a single f2py test that actually runs on any platform, so e.g. the (I am OK with it as is, just realized that this is a bit of a downside, of applying to almost all slow tests, as compilation tests are always slow.) |
|
Let me check - I intended to leave 3 compile tests for f2py, if none are running then something went wrong. |
|
I didn't check super careful, but it seemed to me there were 2 skipped not marked and one that was linux only or so. |
Mark the three f2py test classes that we intentionally leave unmarked as compile-path coverage for the default `pixi run test` invocation, so a future contributor doesn't add `slow` to them. [ci skip]
|
Good catch, something got lost. I pushed a new commit with the fix, and also adding a comment to each of the three tests that they shouldn't be marked slow. They take ~2sec. per test (on M5 Macbook): Three separate tests feels like plenty, could micro-optimize but should be about right. (can be squash-merged now I think, the second commit message isn't very interesting) |
As discussed in gh-31419, the goal is to mark tests with a duration above 0.5-1 sec. on commonly used CPUs (say x86-64 CPU of a few years old) as
slowunless there's a good reason to keep it in the default set that gets executed bynumpy.test()rather thannumpy.test('full').Slowest tests are compile tests for
cythonandf2py, tests for reference cycles and the like, multi-threaded tests, custom memory allocators, and highly parametrized tests that are relatively slow (often dealing with object arrays or other inherently slower features).Most of the changes are for
f2py; almost all compile tests were in the default set - which doesn't really make sense.With this change, we move about 700 out of 47,000 tests to the 'full' mode, resulting in a speedup of the default test() invocation of roughly 50%. Remaining slowest tests recorded in 31419#comment.
Closes gh-31419
AI Disclosure
I did the first several iterations by hand, then asked Claude Code to apply the rest of the markers based on the output of
spin test . -- --durations=50.