Closed
Description
e.g SetEndOfFile in the async path is 50% of the time and it doesn't need to be called (as WriteFile will expand the File).
SetEndOfFile is also a blocking api itself; so expanding the file using it blocks the thread for as much time (or more) as the async saves blocking.
Previous
Seen in electricessence/AsyncFileWriter#1 (Windows 10; netcoreapp2.0 and netcoreapp2.1)
Non-async (just for FileStream.Write)
AsyncFileWriterTester>dotnet run -c Release
100,000 bounded capacity.
Total Time: 2.3680831 seconds
Total Bytes: 115,888,890
Total Wait Time: 00:00:02.6254878
------------------------
10,000 bounded capacity.
Total Time: 2.0399536 seconds
Total Bytes: 115,888,890
Total Wait Time: 00:00:02.3390593
------------------------
1,000 bounded capacity.
Total Time: 2.1499109 seconds
Total Bytes: 115,888,890
Total Wait Time: 00:00:02.3699012
------------------------
100 bounded capacity.
Total Time: 2.0656293 seconds
Total Bytes: 115,888,890
Total Wait Time: 00:00:03.0224013
------------------------
Press ENTER to continue.
Making the change electricessence/AsyncFileWriter@752f7ef
useAsync = true and fs.Write( => await fs.WriteAsync(
Causes a dramatic slow down:
AsyncFileWriterTester>dotnet run -c Release
100,000 bounded capacity.
Total Time: 4.1238278 seconds
Total Bytes: 115,888,890
Total Wait Time: 00:00:14.3291113
------------------------
10,000 bounded capacity.
Total Time: 4.370184 seconds
Total Bytes: 115,888,890
Total Wait Time: 00:00:19.3693952
------------------------
1,000 bounded capacity.
Total Time: 4.1362524 seconds
Total Bytes: 115,888,890
Total Wait Time: 00:00:19.0104628
------------------------
100 bounded capacity.
Total Time: 4.2608508 seconds
Total Bytes: 115,888,890
Total Wait Time: 00:00:20.4615956
------------------------
Press ENTER to continue.
Seems to use a lot of threads, though maybe that's Channels