1. await MyMethnodAsync() and await MyMethnodAsync().ConfigureAwait(true) are they the same from the point of view of program operation?
2. ConfigureAwait(false) always improves performance?
3. When does ConfigureAwait(false) improve performance?
4. When does ConfigureAwait(true) improve performance?

CodePudding user response：

1. at time of writing, "yes, ish"; the "ish" there is because a: there's a small amount of additional code that needs to execute (explicitly storing your preference in a struct, etc), and b: await MyMethnodAsync() works for any awaitable return value of MyMetnodAsync, but .ConfigureAwait is only implemented (at least by default) on some specific (albeit very common) awaitable types; more things are awaitable than you might think; as an example, await Task.Yield().ConfigureAwait(true); does not compile for this reason; the "at time of writing" is because I live in hope that maybe someday there would be some kind of assembly/module-level default that worked with the compiler to automate the default, so for a library you could say, for example, [module:ConfigureAwaitDefault(false)] - but: that does not exist today (nor is it in any plan that I'm aware of)
2. no; if there's no sync-context, it won't make any functional difference - and in many cases (modern asp.net, console exes, service exes, for example) there is no sync-context (by default); and when there is a sync-context, it still isn't guaranteed to make any performance difference; that isn't the point, really; the real point is simply: "if there's a sync-context, do I need to use it? do I actively need not to use it? do I care whether I use it, and if so, should I prefer not to?"; for library code that doesn't have anything to do with UI etc, the answer to that should usually (not always) be "I should avoid it, even if there is one"; for application code, the safest answer is usually "if there's one, I should use it"
3. when a sync-context exists, and would impose some kind of throttle / bottleneck, perhaps due to serializing callbacks over a single worker loop (as is the case for winforms); or worse: where that sync-context could cause a deadlock scenario (I guess a deadlock is the ultimate in bad performance?)
4. in theory, it shouldn't have a performance impact in any direction, other than the trivial step of executing a value-task operation