Skip to content

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

Closed
TomAugspurger opened this issue Oct 26, 2018 · 7 comments
Closed

PERF: Investigate caching on PeriodArray #23359

TomAugspurger opened this issue Oct 26, 2018 · 7 comments
Labels
Performance Memory or execution speed performance Period Period data type

Comments

@TomAugspurger
Copy link
Contributor

Start with benchmarks

  1. ops on PeriodArray and PeriodIndex
  2. ...

If we determine that caching attributes like hasnans and isna does help then we can investigate caching on PeriodArray.

@TomAugspurger TomAugspurger added Performance Memory or execution speed performance Period Period data type labels Oct 26, 2018
@TomAugspurger TomAugspurger added this to the 0.24.0 milestone Oct 26, 2018
@jreback jreback modified the milestones: 0.24.0, Contributions Welcome Nov 25, 2018
@jbrockmendel
Copy link
Member

Could also be useful for NumpyBackedExtensionArray

@TomAugspurger
Copy link
Contributor Author

TomAugspurger commented Dec 19, 2018 via email

@jbrockmendel
Copy link
Member

Been thinking about this recently, I think the view trouble is going to make caching on DTA/TDA/PA infeasible

@TomAugspurger
Copy link
Contributor Author

Is the trouble PeriodArray taking a view on another array, or another array taking a view on the PeriodArray?

@jbrockmendel
Copy link
Member

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 freq removed)

@TomAugspurger
Copy link
Contributor Author

Gotcha. In theory, PeriodArray.__init__ could create a weakref in both directions (view to orig and orig to view) and __setitem__ would invalidate the caches of both. But that feels increasingly fragile.

@jbrockmendel
Copy link
Member

Closing as not worth the trouble

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Performance Memory or execution speed performance Period Period data type
Projects
None yet
Development

No branches or pull requests

3 participants