PERF: cython optimizations #23477
PERF: cython optimizations #23477
Conversation
Codecov Report
@@ Coverage Diff @@
## master #23477 +/- ##
=======================================
Coverage 92.23% 92.23%
=======================================
Files 161 161
Lines 51197 51197
=======================================
Hits 47220 47220
Misses 3977 3977
Continue to review full report at Codecov.
|
gfyoung
added
Performance
pandas/_libs/tslibs/timestamps.pyx
Outdated
| @@ -177,7 +177,7 @@ def round_nsint64(values, mode, freq): | |||
|
|
|||
| # if/elif above should catch all rounding modes defined in enum 'RoundTo': | |||
| # if flow of control arrives here, it is a bug | |||
| assert False, "round_nsint64 called with an unrecognized rounding mode" | |||
| raise ValueError("round_nsint64 called with an unrecognized rounding mode") | |||
There was a problem hiding this comment.
Given that this is a def function, is this error tested in any way (or is this still internal)?
There was a problem hiding this comment.
let's make this an AssertionError
@jbrockmendel : Gosh, I wonder whose "FAULT" that is 😉 |
pandas/_libs/tslibs/timestamps.pyx
Outdated
| @@ -177,7 +177,7 @@ def round_nsint64(values, mode, freq): | |||
|
|
|||
| # if/elif above should catch all rounding modes defined in enum 'RoundTo': | |||
| # if flow of control arrives here, it is a bug | |||
| assert False, "round_nsint64 called with an unrecognized rounding mode" | |||
| raise ValueError("round_nsint64 called with an unrecognized rounding mode") | |||
There was a problem hiding this comment.
let's make this an AssertionError
Happy to do so, though now that I look closer, isn't this redundant with the check at the beginning of the function? |
|
BTW any idea about the double_t thing? |
|
what is the problem with double_t ? |
Yah that's the thing I want to double-check before changing all the places where we currently use |
|
thanks! |
cython was emitting some warnings about untyped array lookups in
tslibs.conversion; added types to thosearr.fill(val)is a python call, whilearr[:]is a C call, so replaced all of thosemodernized an old non-python for-loop, some other small cleanups along the way.
We're running out of available optimizations/cleanups in these files. One thing I'd be interested in changing (but I'm not confident enough to do) is removing uses of
doubleanddouble_t, which I think are equivalent tofloat64_t. But I'm not sure if that is architecture or platform dependent or something.