Dieter Weber

The summary sounds good! > The performance trend needs to keep in mind differences between GPU and CPU. That's an interesting one since we can even have different performance per...

> The main process should be waiting for new results at least for a short time between updates. Probably we should have a moving average since individual updates arrive stochastically,...

> Any pain points regarding our `dask` integrations? For the `DelayedJobExecutor` and `make_dask_array()` we'd still use constant partition sizes. A `DaskDataSet` is quite restricted in its partitioning, as far as...

A small side quest: The tqmd progress bar can't track the number of tasks anymore, but should track processed nav size vs. total nav size.

> As an alternative, one could fire off the reading process for a "raw partition" as a separate Future, Hm, that would increase Dask overheads and wouldn't make much sense...

> That could be replaced with a scheduling component which takes care of starting the next tasks as soon as one finishes, independently from / before the merging that is...

> With the tile scheme negotiation, we have the concept of a "base shape" - for partitioning, this could be handled in a similar manner. 👍 sounds good, ideally using...

My test is very crude, so one should be careful with interpretation. I have a feeling that it does improve somewhat and that the update rate is lowered rather aggressively,...

@sk1p is this still current?

From communication with Gatan: Apparently there's now an option to save or transform 4D DM4 data in an untransposed layout. More details to be discussed! Support for that should be...