Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In the OP for #26032 the Series.any was 223x slower than the ndarray.any. In main it is 6.2x and this gets it down to 2.5x. Let's look at what's left:
We have a few layers in between the Series.any call and nanops.nanany that we could refactor away. These add up to .01+.009+.026+.02=.065 seconds here, about 34% of the total runtime.
The ufunc_config+seterr calls add up to .177s here. Disabling theUpdate: did this after determining that we already set errstate within the relevant nanops functions.with np.errstate(all="ignore")
inSeries._reduce
cuts the timeit result down to 9us. It also doesn't break any tests or surface any warnings in the tests._get_values is still
more than halfupdate:a quarter of nanany,and more than half of _get_values is in extract_array. According to the annotation the extract_array is unnecessary (though it is necessary for the doctests and a handful of tests in test_nanops).update: the extract_array has now been removed.So there is still some room for optimization, but some of it would be more invasive than this. I would be +1 on making all these optimizations, will wait for a little buy-in first though.