阻止操作最终会更快吗？还是只在它“一直异步”时才获得真正的好处？
因此，多年来，我在多线程应用程序和并发优化上花费了很多时间。
async-await是天赐之物[感谢所有参与实现这一目标的人。]
但是我已经进行了很多测试和实验，由于各种原因，我继续返回可重复的结果，在此过程中，阻塞版本的速度更快，在某些情况下也是如此。
我非常了解这个理论，并且在很多情况下，监视 异步要好得多。但是这些奇怪的原因
这可能仍然是正确的，但是记录到FileStream的一个错误是.WriteAsync()正在执行额外的处理，从而降低了速度。好的，没问题，我只做.Write（）。
也就是说，测试Channel（异步）与BlockingCollection（用于将数据排队到FileStream）的使用会产生以下令人困惑的结果：
（阻止操作最终会更快吗？）
STANDARD BENCHMARKS:
Total Bytes: 115,888,890
File stream standard benchmark. (for loop)
Total Elapsed Time: 1.8994005 seconds
------------------------
Synchronized file stream benchmark. (in parallel with lock)
Total Time: 1.6911277 seconds
Aggregate Waiting: 00:00:03.6219495
------------------------
TESTS WITH PARTIAL BLOCKING: (all fed in parallel)
150,000 capacity BlockingCollection.
Total Time: 1.9066117 seconds
Aggregate Waiting: 00:00:01.8377548
------------------------
150,000 capacity Channel.
Total Time: 2.8085457 seconds
Aggregate Waiting: 00:00:10.0840823
------------------------
100,000 capacity BlockingCollection.
Total Time: 2.0116308 seconds
Aggregate Waiting: 00:00:01.9312396
------------------------
100,000 capacity Channel.
Total Time: 2.2340504 seconds
Aggregate Waiting: 00:00:14.3782481
------------------------
50,000 capacity BlockingCollection.
Total Time: 2.0616825 seconds
Aggregate Waiting: 00:00:07.4741103
------------------------
50,000 capacity Channel.
Total Time: 1.9812716 seconds
Aggregate Waiting: 00:00:01.5531377
------------------------
10,000 capacity BlockingCollection.
Total Time: 1.7345184 seconds
Aggregate Waiting: 00:00:01.6600510
------------------------
10,000 capacity Channel.
Total Time: 4.6379626 seconds
Aggregate Waiting: 00:01:06.4975673
------------------------
https://github.com/electricessence/AsyncFileWriter/tree/netcore