MAINT: speed up _block by avoiding a recursive closure#11991
MAINT: speed up _block by avoiding a recursive closure#11991mattip merged 2 commits intonumpy:masterfrom
_block by avoiding a recursive closure#11991Conversation
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! |
ahaldane
left a comment
There was a problem hiding this comment.
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.