Open dannyjacobs opened 4 years ago
@dannyjacobs should this be labelled as UVData related or are you worried about other objects as well?
I think just uvdata. Sorry didn’t think about labeling.
On Thu, Dec 5, 2019 at 7:53 PM Bryna Hazelton notifications@github.com wrote:
@dannyjacobs https://github.com/dannyjacobs should this be labelled as UVData related or are you worried about other objects as well?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/RadioAstronomySoftwareGroup/pyuvdata/issues/729?email_source=notifications&email_token=AAAPNV75BZAXV4REHJHT3FTQXG5C5A5CNFSM4JU5Z5C2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGC3HYY#issuecomment-562410467, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAPNV5OBXLRF6SNPAGEHI3QXG5C5ANCNFSM4JU5Z5CQ .
-- Sent from Gmail Mobile
@mkolopanis has implemented several recent speed ups, both of the code and of the tests themselves. We do get total test suite timing from the CIs, but could add the durations
keyword to get the timing of the slowest n tests.
speeding up _key2_inds might also be related: #201
Some other issues/PRs related to some recent speed ups: #800 #813 #815 #818 #825 #834 #840
Occasionally I hear that pyuvdata is slow, though without further investigation this complaint is impossible to decouple from the size of the data being read.* However since we do not currently track execution time of our various tasks, it is possible for a change to be introduced which increases execution time. This is difficult to monitor at scale because large files and extended execution times are not easily supported within the current testing infrastructure. Here are a few possible things we could do:
*The following is a digest of a discussion on the 3 Dec 2019 pyuvdata telecon.