lorenzoh

Interesting 🤔. I wonder if it would be enough to do that every few steps only and what the memory usage curve would look like

I'm not all too familiar with the way MLJFlux.jl currently handles this, but I'll try to give some comments and what our current approach on the deep learning side is....

See the FluxTraining.jl documentation: https://lorenzoh.github.io/FluxTraining.jl/dev/docs/features.html#logging

Should this be closed? I think FluxTraining.jl provides nice enough [integration with TensorBoard](https://lorenzoh.github.io/FluxTraining.jl/dev/docs/features.html#Logging).

Right, I didn't think of the latency. I think what you're proposing makes sense, and makes for an easier migration as well.

As another data point, the import time difference is also quite big on my machine: ```julia julia> @time using MLUtils 0.222900 seconds (468.17 k allocations: 27.956 MiB, 1.72% compilation time)...

Would it be possible to add `parallel` as an experimental option? Could be removed later by simply ignoring it. Thinking through it, I think it would be better to have...

Yes, the load time is already released.

Sometimes you want a batch view that gives you a vector of observations (e.g. different-sized images), and sometimes you'll want to have them as a single array (or recursively collate...

Yup 👍 This is necessary for porting the buffered batch view from DataLoaders.jl