Commented by: @cincuranet

Yes, this is partly expected. The async support added non-trivial pieces of code and for a "non-parallel" workloads this adds up. It's on my radar to start chopping pieces and improve it, but also with scalability in mind. I already have some pieces tested with small improvements.

Commented by: Rand Random (rand.random)

I have added a parallel workload to my test project.
Currently it is faster to wrap code from the 7.10.1 version inside Task.Run than to use 8.0.1 async feature.

On 7.10.1 my test finishes in parallel with 6.12 s, compared to ~ 11s not executing in parallel.
On 8.0.1 my test finishes in parallel with 16.01 s, compared to ~ 28s not executing in parallel.
Running non parallel differs slightly if I use non async methods or async methods or if I wrap code inside Task.Run, though everything seems in the margin of error.

I have split up the process of reading 1 million records into 10 tasks each reading 100.000 records.

To read the data in blocks of 100.000 records I have altered FOO1 in the table FOO to have a primary key to get an index read for the query.
select * from foo where foo1 between 0 and 100000

You can find the altered database in TESTPERFv2.7z.
The updated results with the 2 new benchmarks for parallel execution can be found in per7 - parallel.jpg and per8 - parallel.jpg.

I did a quick look today. As expected the state machines generated are not helping. I need to dig into it and try to lower the impact (without implementing (and maintaining) everything twice).

Other thing to consider is whether the communication is over localhost or "real" network. Because with real network there's real asynchronicity.

Over Internet, with 20k fetches:

Obviously that doesn't mean the localhost performance is not important. Quite the contrary.

cc @Rand-Random