Open hendrikmakait opened 4 days ago
Thanks for opening your first issue here at xarray! Be sure to follow the issue template! If you have an idea for a solution, we would really welcome a Pull Request with proposed changes. See the Contributing Guide for more. It may take us a while to respond here, but we really value your contribution. Contributors like you help make xarray better. Thank you!
This is using the sliding_window_view
trick under the hood, which composes badly with anything that does a memory copy (like weighted
in your example)
We actually use this approach for .rolling.mean
but are clever about handling memory copies under the hood (https://github.com/pydata/xarray/pull/4915).
I'm not sure what the right solution here is.
"window"
to be singly-chunked by default I think.NaN
s in rolling.construct
. This has downstream consequences (np.nanmean
uses a memory copy for example). But this is a more complex fix: https://github.com/pydata/xarray/pull/5603PS: I chatted with @phofl about this at FOSS4G. He has some context.
Yeah this is definitely on my todo list and @hendrikmakait and I chatted briefly about this today, there is definitely something we have to do
I support the approach, but it'd be good to see the impact on ds.rolling().mean()
which also uses construct
but is clever about it to avoid the memory blowup.
I also wonder if instead of using rolling().construct().weighted().mean()
there should just be something like rolling().weighted().mean()
or rolling().mean(weights=...)
. From what I understand, the quadratic explosion of the shape and the chunks is not inherent to this computation but we could also solve it akin to a map_overlap
computation.
Yes, https://github.com/pydata/xarray/issues/3937, but we've struggled to move on that.
construct
is a pretty useful escape hatch for custom workloads, so we should optimize for it behaving sanely.
What happened?
When using `rolling(...).construct(...) in https://github.com/coiled/benchmarks/pull/1552, I noticed that my Dask workers died running out of memory because the chunk sizes get blown up.
What did you expect to happen?
Naively, I would expect
rolling(...).construct(...)
to try and keep chunk sizes constant instead of blowing them up quadratic to the window size.Minimal Complete Verifiable Example
MVCE confirmation
Relevant log output
No response
Anything else we need to know?
No response
Environment