Proposal: Inline async method

[RamType0]

Currently,each async method creates one state machine.
I wanna combine state machine with nested async method invocation.
It works like F# inline methods, assembly internal only.

[svick]

I wanna combine state machine with nested async method invocation.

Why? If it's to improve performance, can you show how much this would help you in a realistic scenario?

[RamType0]

I wanna combine state machine with nested async method invocation.

Why?

For performance.

If it's to improve performance, can you show how much this would help you in a realistic scenario?

Here's test project.

I got this kind of result.

BenchmarkDotNet=v0.12.1, OS=Windows 10.0.18363.778 (1909/November2018Update/19H2)
Intel Core i9-9900K CPU 3.60GHz (Coffee Lake), 1 CPU, 16 logical and 8 physical cores
  [Host]        : .NET Framework 4.8 (4.8.4150.0), X64 RyuJIT
  .NET 4.8      : .NET Framework 4.8 (4.8.4150.0), X64 RyuJIT
  .NET Core 3.1 : .NET Core 3.1.3 (CoreCLR 4.700.20.11803, CoreFX 4.700.20.12001), X64 RyuJIT
  Mono 6.8.0    : Mono 6.8.0 (Visual Studio), X64

Method	Job	Runtime	Mean	Error	StdDev
NestedNoAsync	.NET 4.8	.NET 4.8	1,072.12 ns	1.803 ns	1.599 ns
InlineNoAsync	.NET 4.8	.NET 4.8	47.65 ns	0.257 ns	0.214 ns
NestedYieldOnce	.NET 4.8	.NET 4.8	6,879.69 ns	125.388 ns	117.288 ns
InlineYieldOnce	.NET 4.8	.NET 4.8	1,560.72 ns	20.274 ns	17.973 ns
NestedYieldEach	.NET 4.8	.NET 4.8	41,376.44 ns	358.283 ns	335.138 ns
InlineYieldEach	.NET 4.8	.NET 4.8	29,016.23 ns	84.470 ns	79.013 ns
NestedNoAsync	.NET Core 3.1	.NET Core 3.1	564.90 ns	0.638 ns	0.597 ns
InlineNoAsync	.NET Core 3.1	.NET Core 3.1	18.12 ns	0.230 ns	0.215 ns
NestedYieldOnce	.NET Core 3.1	.NET Core 3.1	3,217.08 ns	31.706 ns	29.658 ns
InlineYieldOnce	.NET Core 3.1	.NET Core 3.1	849.34 ns	3.877 ns	3.238 ns
NestedYieldEach	.NET Core 3.1	.NET Core 3.1	28,945.69 ns	577.294 ns	809.285 ns
InlineYieldEach	.NET Core 3.1	.NET Core 3.1	20,666.05 ns	166.498 ns	155.742 ns
NestedNoAsync	Mono 6.8.0	Mono 6.8.0	891.03 ns	2.358 ns	2.206 ns
InlineNoAsync	Mono 6.8.0	Mono 6.8.0	40.26 ns	0.035 ns	0.029 ns
NestedYieldOnce	Mono 6.8.0	Mono 6.8.0	16,797.55 ns	311.562 ns	305.996 ns
InlineYieldOnce	Mono 6.8.0	Mono 6.8.0	10,095.49 ns	200.777 ns	396.314 ns
NestedYieldEach	Mono 6.8.0	Mono 6.8.0	178,924.15 ns	538.445 ns	503.661 ns
InlineYieldEach	Mono 6.8.0	Mono 6.8.0	157,137.39 ns	3,116.256 ns	8,154.698 ns

• XXXNoAsync
  It is marked as async,but it completes synchronously.
  In this pattern, no state machines would be created in heap.(Thanks for ValueTask)
• XXXYieldOnce
  Call "Task.Yield" and awaits it once. The most blatant, but still realistic scenario(Because async is "infectious").
  • InlineYieldOnce creates one state machine in heap,and continuations are invoked from delegate once.
  • NestedYieldOnce creates 21 state machines in heap,and continuations are invoked from delegate 21 times.
• XXXYieldEach
  Call "Task.Yield" twenty times and awaits it each times.

Each NestedXXX and InlineXXX method doing exactly same things.
But in every scenario, InlineXXX was definitely faster.

[CyrusNajmabadi]

It's unclear what is being asked for here. Can you explain what codegen you would want given an existing code pattern that is written?

[RamType0]

Currently ,if we write this kind of code,these are 5 state machine and 5 tasks created every time we call ShowImageAsync.

async ValueTask ShowImageAsync(string url)
{
   var blob = DownloadBlobAsync(url);
   await RenderImageAsync(blob);
}

async ValueTask<byte[]> DownloadBlobAsync(string url)
{
   var connection = await ConnectAsync(url);
   return await RequestBlobAsync(connection,url);
}

async ValueTask<Connection> ConnectAsync(string url)
{
   ConnectAsync code
}
async ValueTask<byte[]> RequestBlobAsync(Connection connection,string url)
{
   RequestBlobAsync code
}
async ValueTask RenderImageAsync(ReadOnlyMemory<byte> blob)
{
   RenderImageAsync code
}

We could reduce number of tasks,async state machines by this kind of code generation.

async ValueTask ShowImageAsync(string url)
{
   var connection = await  ConnectAsync code;
   var blob = await RequestBlobAsync code;
   await RenderImageAsync code;
}

async ValueTask<byte[]> DownloadBlobAsync(string url)
{
   var connection = await  ConnectAsync code;
   return await RequestBlobAsync code;
}

async ValueTask<Connection> ConnectAsync(string url)
{
   ConnectAsync code
}
async ValueTask<byte[]> RequestBlobAsync(Connection connection,string url)
{
   RequestBlobAsync code
}
async ValueTask RenderImageAsync(ReadOnlyMemory<byte> blob)
{
   RenderImageAsync code
}

With this code generation, only one state machine and task are created every time we call ShowImageAsync.

[CyrusNajmabadi]

We could reduce number of tasks,async state machines by this kind of code generation.

I don't see how that would be ok. it would be inlining all the code (transitively) of all async methods called. That would greatly increase the side of htese methods.

[alrz]

Similar to #15491

[RamType0]

That would greatly increase the side of htese methods.

You mean the size of these methods?
As I said at the beginning,it works like F# inline methods.
Yeah,F# is already doing such a thing,and is it said that F# inline method's assembly size increasing are harmful?

[alrz]

it would be inlining all the code (transitively) of all async methods called. That would greatly increase the side of htese methods.

Instead of inlining the whole code, can't we just pass the state machine instance to the nested method, so it could modify the state on an existing state machine.

meaning: we still have method boundaries but all of them operate on a single state machine.

[jinujoseph]

Duplicate of #22052

[sharwell]

cc @genlu

[sharwell]

@RamType-0 we are interested in providing an "inline method" feature more broadly. This issue captures one possible use case, but there are many different teams that could benefit from having this available in different ways. I believe we are starting fairly conservatively with the implementation approach, but would be interested in expanding coverage to new scenarios as they are identified with use of the feature.

[svick]

@jinujoseph @sharwell How is this a duplicate? #22052 is about a refactoring (i.e. something that changes the C# code in the editor), while, as I understand it, this issue is about a compiler feature (i.e. something that keeps the C# code intact, but changes the generated IL).

Since the two have completely different goals (one is all about removing abstraction, the other is about maintaining it), I don't see how one could be a duplicate of the other.

[sharwell]

@svick I was going based on the information in the first post, which I see is ambiguous. If this is a request for the compiler to automate this inlining (as opposed to a refactoring of the code itself), then this would be a duplicate of #15491.

[jmarolf]

yeah, this is asking for a compiler optimization I do not think this should be tracked as part of #22052

[sharwell]

Duplicate of #15491

[jmarolf]

that is the correct dupe :)