-
-
Notifications
You must be signed in to change notification settings - Fork 10.8k
MAINT: Fix all special-casing of dtypes in count_nonzero
#9849
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
Conversation
Looks good to me, if only for the increase in clarity. |
Looks like this fails for some dtypes. From Travis:
|
0433d5b
to
c94e2c5
Compare
A quick profile reveals that `int.astype(bool)` is faster than `int == 0` anyway
c94e2c5
to
fb168b8
Compare
That should hopefully trigger a retest now that #9856 is in |
@shoyer Tests now pass |
I'm struggling to get Two consecutive runs give wildly (~50%) different results on the same commit, so comparisons are meaningless. Even more concerningly, some benchmarks complete instantaneously, and it's a different set each time. I reckon we just merge this, and see what the online asv has to say |
Thanks Eric. |
Massive improvement for Maybe the special casing of |
Although actually, a performance hit for very large object arrays, presumably because we now allocate a large boolean array too. |
This is a redo of #7177
Rationale:
int.astype(bool)
is marginally faster thanint == 0
(profiled as ~5%)bool.astype(bool, copy=False)
should be comparable to a pythonif
apply_along_axis
is slow, and probably loses whatever we gain by avoidingsum
I haven't rerun @gfyoung's benchmark suite that came with #7177
This also won't pass until
#9848#9856 is merged