Question

• I’m creating ViewModel objects in a loop inside BackgroundWorker’s DoWork
• I’m reporting progress in each iteration, passing the new object as an argument to be retrieved by ProgressChanged handler (which is friends with the UI thread)
• In that handler, the object is added to an ObservableCollection with ListBox bound to it.

MY ViewModel class contains two string properties (Filename and ThumbnailPath), and its DataTemplate contains a Label and an Image, bound to these properties.

void bw_DoWork (object sender, DoWorkEventArgs e) {
   List<string> files = e.Argument as List<string>;
   FileInfo fi; int percent;
   for (int i = 0; i < files.Count; i++) {
      FileViewModel newItem = new FileViewModel(files[i]);
      fi = new FileInfo(files[i]);
      percent = i / files.Count * 100;
      bwImportBrowserItems.ReportProgress(percent, newItem);
   }
}

void bw_ProgressChanged (object sender, ProgressChangedEventArgs e) {
    this.observableCollection.Add(e.UserState as FileViewModel);
}

Typical behavior for a typical number of items (30-50): UI freezes for about 2-3 seconds; around a half of the items is displayed; UI freezes again for a shorter time and the rest is added.

Now I understand it’s not the best idea to call UI updates from a loop – I figured the calls come so frequently the UI doesn’t have time to respond to them, that’s why we see the UI being updated “in groups”, leaving it unresponsive in the meantime.

I tried adding Thread.Sleep(500) as the last line of the loop. This helped me illustrate that everything works as it should, because with this slowdown, the items were being added nicely one after another without any nonresponsiveness.

So I tried different sleep values and settled for Thread.Sleep(25). This is not ideal but quite acceptable and comes pretty close to what it should look like.

I’d like to ask if the Thread.Sleep is a common workaround in situations like these, and also what is the general solution people go with in this situation: to update an UI collection from a background loop without ANY unresponsiveness at all.
I’ve also come up with some ideas and I’d appreciate your comments.

Ideas I can think of:

1. Don’t ReportProgress so often – limit it to 10 times, or to every 10
   new items.
2. Don’t do it in a loop. Create a list of items that need to be
   created. In the DoWork body, dequeue ONE item from the list,
   instantiate and return ViewModel instance. On RonWorkerCompleted,
   update the UI, check if our list is empty, and if not,
   RunWorkerAsync again.

Answer 1

if the Thread.Sleep is a common workaround in situations like these

Consider it a last resort. You are increasing the total processing time (not CPU load).

1) Don’t ReportProgress so often – limit it to 10 times, or to every 10 new items.

That is the basic idea. Collect new Items and dispatch a List through ReportProgess. Tune the size of the list.

2) Don’t do it in a loop.

Possible, but your 1-item per Bgw looks a lot slower. It might even show the same symptoms.

3) Decouple through a ConcurrentQueue. You can let DoWork fill a Queue and a Dispatcher.Timer could empty it. Also try to process batches with that timer. You can tune the priority of the timer and the batch size.