-
-
Notifications
You must be signed in to change notification settings - Fork 18.4k
REF: de-duplicate DST tzconversion code #35077
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
also rebase |
Pretty much every variant of this I can come up with segfaults on Linux but not on Mac. cc @chris-b1 any thoughts? |
Any chance you've tried to debug the segfault using the steps outlined in #35100? Might be helpful to step through the debugger (replace lldb with gdb for linux most likely) |
@jbrockmendel which test(s) are segfaulting? I don't see any in CI |
They're not segfaulting ATM because they are being caught by debugging assertions first. e.g. https://dev.azure.com/pandas-dev/pandas/_build/results?buildId=38537&view=logs&j=a3a13ea8-7cf0-5bdb-71bb-6ac8830ae35c&t=add65f64-6c25-5783-8fd6-d9aa1b63d9d4&l=160 the assertion that raises is https://github.com/pandas-dev/pandas/pull/35077/files?file-filters%5B%5D=.pxd&file-filters%5B%5D=.pyx#diff-03511a52390e3160aa5d428a7b45a4f4R57, but if we get to that line, then we should have already executed https://github.com/pandas-dev/pandas/pull/35077/files?file-filters%5B%5D=.pxd&file-filters%5B%5D=.pyx#diff-4260fb485bcfabb1da9cc5a85ed6d639R265, which isnt raising despite asserting the same thing. Locally I just got a segfault inside tests.frame.test_to_csv, but running the tests on just that file generally doesnt produce the segfault (well, 2 runs out of the last 5) |
This seems to confirm the suspicion that this is a
|
My latest thought is that the |
^ expanding on the above, if within info.positions = <intp_t*>cnp.PyArray_DATA(pos) to from libc.string cimport memcpy
from cpython.mem cimport PyMem_Malloc
info.positions = <intp_t *>PyMem_Malloc(n * sizeof(intp_t))
memcpy(info.positions, pos.data, n * sizeof(intp_t)) Then the tests pass. This is probably not the best way to code this and leaks memory as is, but I think confirms the suspicion that memory management in |
This seems right, good call. In a different branch where I use a cdef class instead of a struct, retaining the |
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.
cool looks good. yea this approach probably works better with automatic memory management
int noffsets | ||
int64_t* utcoffsets | ||
intp_t* positions | ||
ndarray positions_arr # needed to avoid segfault |
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.
Do we even need both positions_arr and positions or can we just use the former?
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.
we could just use the former, but i think we get a perf boost from indexing on the latter
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.
If you can see a difference then sure, but if not would definitely be cleaner to just stick with the ndarray
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.
lgtm, when you are happy @WillAyd
ATM getting a non-trivial perf hit; I think I didnt see this with the struct version
|
If I can't get the perf figured out here, we can at least get some mileage de-duplication-wise by sharing+inlining some helpers following #35168 |
If the struct version is faster you could also memcpy the bytes needed; would just need a cleanup function to free them whenever done with the struct |
The struct version is a little bit faster, but still a non-trivial perf hit:
|
Closing, will revisit following #35168 |
This implements TZConvertInfo to de-duplicate a bunch of tzconversion code. This uses the new pattern on get_resolution. The other usages I intend to update in individual follow-ups in which I'll check that we have good asv coverage the affected functions.
Sits on top of #35075 (actually, that was broken off of this)
Perf-improving according to the newly implemented asvs:
L50-L57 in libresolution is going to end up being repeated, should become a helper function. Doing that separately since it tentatively looks like that may have a perf hit if not done carefully.
xref 652a3de#r30437889