-
-
Notifications
You must be signed in to change notification settings - Fork 18.4k
PERF: Investigate caching on PeriodArray #23359
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
Comments
Could also be useful for NumpyBackedExtensionArray |
We'll need to be especially careful here. The point of PandasArray
(formerly NumPyBackedExtensionArray) is to be a zero-copy view on some
other ndarray,
which makes failing to invalidate a cache more likely.
…On Tue, Dec 18, 2018 at 10:26 PM jbrockmendel ***@***.***> wrote:
Could also be useful for NumpyBackedExtensionArray
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#23359 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABQHIjBMrM-zH4Fg3xguEb_RZgyHqydRks5u6b_3gaJpZM4X8PLp>
.
|
Been thinking about this recently, I think the view trouble is going to make caching on DTA/TDA/PA infeasible |
Is the trouble PeriodArray taking a view on another array, or another array taking a view on the PeriodArray? |
its one PeriodArray taking a view on another, so if the first does a setitem (that presumably invalidates the cache), the cache would need to be invalidated on the other (this is also why im increasingly convinced that DTA/TDA need to have |
Gotcha. In theory, |
Closing as not worth the trouble |
Start with benchmarks
If we determine that caching attributes like
hasnans
andisna
does help then we can investigate caching on PeriodArray.The text was updated successfully, but these errors were encountered: