-
Notifications
You must be signed in to change notification settings - Fork 283
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
Extracting a time range from a cube is slow #4957
Comments
This was previously raised at #3609, which went stale. So I think this is a desirable feature that no-one got around to addressing yet. |
Fancy taking it on @rcomer ? 😉 |
I think @bouweandela was offering to put something up, and has clearly already given it more thought than I have! |
Yes, I already tried to implement something. I'll open a pull request and we can see from there.. |
Just opened a pull request here: #4969 |
📰 Custom Issue
Extracting a time range as described in the documentation is quite slow if you want to do it for many cubes and/or cubes with many time points. For a single cube with 10000 time points it already takes 2 seconds on my computer, so if I want to subset a few hundred cubes that becomes quite slow.
Here is a script that demonstrates this:
Result:
From looking at the code in
iris.coords
, it looks like the slow behaviour is caused by converting all time points to datetimes individually for each cell, instead of converting them once and then generating the cells.Here is some code with timings:
and
If this is an interesting feature, I can make a pull request to change the code so it first converts all the time points and then generates the cells?
The text was updated successfully, but these errors were encountered: