-
-
Notifications
You must be signed in to change notification settings - Fork 10.8k
MAINT: speed up _block
by avoiding a recursive closure
#11991
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
91391c1
to
1af752a
Compare
This mostly just undoes the speed regression caused by #11910, I think |
@mattip, thoughts? I'm not sure how I feel about micro-optimizations like this that come at varying clarity costs. |
1af752a
to
eedd445
Compare
It seems good to me, removing that recursive closure is +1 for clarity, and other than that it just seems to juggle the same functions that were called before as far as I am concerned. I am personally not a big advocate of one-line functions, they break up the flow for me, so I would prefer to inline |
@hmaarrfk: Regarding benchmarks - it's usually valuable to make them in a separate PR, so that it can be merged first, and given time to show up in https://pv.github.io/numpy-bench/#/summarylist |
eedd445
to
9779e69
Compare
@eric-wieser You are right that it was a regression caused by that commit. It is pretty clear from the ASV history. ASV is pretty cool! |
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.
I like it. No more magic involving @recursive
, code is still clear.
Thanks @hmaarrfk |
_block
by avoiding a recursive closure
This is a small PR that speeds up the case of blocking small arrays by 10-20% in CPython 3.6 by avoiding closures.
This only makes PR #11971 a harder sell, but I think these optimizations are worthwhile for people blocking small arrays.
Benchmarks Python 3.6 conda(-forge?)
Benchmarks python 3.5 conda(-forge?)
Benchmarks Python 2.7 conda(-forge)
Pinging @eric-wieser who helped me with #11971
and @jakirkham and @j-towns who contributed to np.block in #9667.