These performance results were obtained using the test package in accordance with a standard testing methodology. All tests read a 4GB file.
When using FileStreams, the number of bytes read or written at once can have an unexpected effect on performance. On the test machine FileStream I/O speed varied depending on how large the buffer was (and consequently how many bytes were requested at once from the OS). Below are the times taken to read a 4GB file, requesting 100KB at a time with six FileStreams of varying buffer size:
Unlike FileStreams, BufferedStreams and BetterBufferedStreams, AsyncStreams do not read in their entire buffer at once and default to reading between {buffer size}/4 and {buffer size}/2 bytes at a time. Consequently, an apple-to-apple comparison of an AsyncStream to the other streams with the same buffer size is not possible. To counter this, at every buffer size (100KB, 1MB, 10MB) we also test an AsyncStream with twice the buffer (200KB, 2MB, 20MB) that always reads the same number at once as the other streams do (100KB, 1MB and 10MB).
The particularly poor file I/O speed at 512KB is why the 1MB AsyncStream appears so slow in these tests, but remember that this is an artifact of the underlying FileStream, not a problem with the AsyncStream itself.
Sequential Read
Description: reads the entire file by repeatedly calling Read() until the
end-of-file is reached.
Purpose: demonstrates that the overhead added by the wrapper streams (BufferedStream,
BetterBufferedStream, and AsyncStream) is small.
Seek
Description: alternates between reading a chunk of data and seeking
forward in the file (e.g. the 1KB seek test reads 1024 bytes and then skips the
next 1024 bytes).
Purpose: demonstrates that replacing an inefficient FileStream or
BufferedStream with a BetterBufferedStream or AsyncStream can (greatly) improve
efficiency when seeking.
SHA512
Description: computes the SHA512 hash of the file.
Purpose: demonstrates one of the advantages of asynchronous I/O--the
program can do other work (in this case, hashing) while data is being read from
the disk.
Read-Wait
Description: spin-waits a millisecond after every 400KB is read
Purpose: similar to the SHA512 test, but artificial (instead of hashing,
no useful work is performed--just a timed loop).
Given the same file I/O size, all tested streams were approximately as fast, indicating negligible overhead over a FileStream alone.
Note that the FileStream and BufferedStream with 10MB buffer were not tested due to the amount of time required.
AsyncStream has a large performance advantage because asynchronous I/O allows the CPU to perform other work as bytes are transferred from disk into memory, whereas the other streams must block.
Results are similar to those of the SHA512 test, though less pronounced.
