In step 1, we created an iterator using AsyncMultiDataSetIterator. We can use  AsyncMultiDataSetIterator or AsyncDataSetIterator to create asynchronous iterators. There are multiple ways in which you can configure an AsyncMultiDataSetIterator. There are multiple ways to create AsyncMultiDataSetIterator by passing further attributes such as queSize (the number of mini-batches that can be prefetched at once) and useWorkSpace (a Boolean type indicating whether workspace configuration should be used). While using AsyncDataSetIterator, we use the current dataset before calling next() to get the next dataset. Also note that we should not store datasets without the detach() call. If you do, then the memory used by INDArray data inside the dataset will eventually be overwritten within  AsyncDataSetIterator. For custom iterator implementations, make sure you don't initialize something huge using the next() call during training/evaluation. Instead, keep all such initialization inside the constructor to avoid undesired workspace memory consumption.

In step 2, we created an iterator using AsyncShieldDataSetIterator. To opt out of asynchronous prefetch, we can use AsyncShieldMultiDataSetIterator or AsyncShieldDataSetIterator. These wrappers will prevent asynchronous prefetch in data-intensive operations such as training, and can be used for debugging purposes.

If the training instance performs ETL every time it runs, we are basically recreating the data every time it runs. Eventually, the whole process (training and evaluation) will get slower. We can handle this better using a pre-saved dataset. We discussed pre-save using ExistingMiniBatchDataSetIterator in the previous chapter, when we pre-saved feature data and then later loaded it using ExistingMiniBatchDataSetIterator. We can convert it to an asynchronous iterator (as in step 1 or step 2) and kill two birds with one stone: pre-saved data with asynchronous loading. This is essentially a performance benchmark that further optimizes the ETL process.