What can be done to help extensions be performant off the UI thread?

[mrlacey]

It's depressing and frustrating when the yellow info bar of shame says that Visual Studio is running slow (or froze/stopped responding for N seconds) because of an extension that you're written.

I'm aware of the VS Threading cookbook but I still have issues.
When starting out with extension development it would be great if it was easier to avoid common problems in this area and "fall into the pit of success."

The threading analyzers are good at indicating when it's necessary to switch to the UI thread to use specific classes or methods, but this can quickly lead to switching to the UI thread at the start of method or extension activation points and never leaving.

It would be nice if there was a way (another analyzer perhaps) to highlight when working on the UI thread when the code doesn't need to be there. This would be a compliment to the existing analyzer that says when switching to the UI thread is necessary.

However, I'm aware that repeatedly switching between threads can bring its own issues and also impact performance. Is there a better way?

What do others do to ensure being performant and off the UI thread as much as possible?
And, what else can be done to improve things? (other than wait for v17)

[madskristensen]

It would be nice if there was a way (another analyzer perhaps) to highlight when working on the UI thread when the code doesn't need to be there. This would be a compliment to the existing analyzer that says when switching to the UI thread is necessary.

I love this idea. Perhaps @AArnott knows of any patterns we can include in the analyzers.

Personally, I handle this manually. Use fire and forget when I don't care about waiting for the results. This seems to be effective, but I'm not sure it is best practice.

[AArnott]

@madskristensen I hope your fire and forget code follows the guidelines here: https://github.com/microsoft/vs-threading/blob/main/doc/cookbook_vs.md#how-to-write-a-fire-and-forget-method-responsibly

I don't think we would ever write an analyzer to suggest switching off the main thread. The reason being that even if we could reliably say that all the code for a given section of an async method is free-threaded (which by itself is a tall order), being free-threaded does not imply that it is also thread-safe. For example if you have an async method that starts on or switches to the main thread and then accesses a Dictionary<K,V> in a field, that is all free-threaded code and we may say does not require the main thread. But the main thread is also serving as a de facto lock, guaranteeing that the dictionary is never accessed concurrently. Moving the accessing code to the threadpool would remove that, and may lead to data corruption and/or exceptions.

Moving code to the threadpool is great, but it very much requires domain knowledge of the code being written.

Personally the way I handle this is two-fold:

1. For VS-specific code, I tend to default to the main thread because it's easiest to write accurate code and respect thread requirements of thread-affinitized code. Use async methods wherever available. Where the code may be heavy (due to loops or calling sync APIs that may be heavy), that's when I take the time to verify it is thread-safe and free-threaded and then switch to a background thread.
2. For VS-agnostic code, always write it to be thread-safe and document it as such. This has become second nature to me but thread-safety can be a steep learning curve, and can involve more than just adding lock at key places.

[madskristensen]

It does follow the guidelines. No async void for instance

[AArnott]

The guideline I was thinking about was not dropping the resulting Task on the floor, but instead tracking it in your AsyncPackage.JoinableTaskCollection.