Question

Both iterators and async methods create a state machine for keeping the state between yield/await operations and every local in your method becomes a field in that instance of the state machine type.

In this talk, Stephen Toub talks about having less local variables in the bodies of async methods is a valid (no micro) optimization if you have lots of await calls. (i.e. if you’re awaiting in a loop)

So in this case, I wonder the performance difference between having 7 locals and having one local which is a Tuple<T1, T2, T3, T4, T5, T6, T7> .

Obviously, it does nothing but to complicate things if there is only one yield in the iterator or only one await in the async method but when it comes to thousands or more, do you think using tuples (or any other type that will wrap your fields) do any good?

Or would that be just another micro-optimization attempt that accomplishes nothing or too less to use?

Edit: Now that I thought it again, it would already be implemented that way if it would do any good, I suppose. Nonetheless, I’m still curious about it.

Answer 1

If you have thousands of await/yield, then something is already very wrong. It should also be noted that the two have different implementations. However, changing to a tuple isn’t adding anything useful, IMO. You are still storing (as state) a single reference in either case, no matter whether that reference is:

• the iterator instance
• a captured-variable context
• a tuple
• a captured-variable context to a tuple

But by using a tuple you guarantee you need a new instance any time you need to mutate a variable.

Tulle can be more interesting when implementing async manually (things like ContinueWith), but I really don’t think it is worth it when using the compiler to provide the implementation.