Home
Forums
New posts
Search forums
Articles
Latest reviews
Search resources
Members
Current visitors
Newsgroups
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Menu
Log in
Register
Install the app
Install
Home
Forums
Newsgroups
Microsoft DotNet
Microsoft Dot NET Framework
Disk file write performance
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
[QUOTE="Richard Grimes [MVP], post: 6643605"] Lee Gillie wrote: I've not done the analysis with file writes, but I have for reads. Having said that, the notes below would (in general) apply to writes as well as to reads. Win32 disk reads and writes always use async access. If you don't use an OVERLAPPED structure for ReadFile/WriteFile then the function will block until the operation completes, if you use OVERLAPPED then the function will return as soon as the operation is initiated and you get the notification through your OVERLAPPED structure or through the thread bound to the controlling IO completion port. In effect, the underlying file driver code is the same for both sync and async. The FileStream async methods call ReadFile/WriteFile and bind the file handle to a threadpool thread so that when the action is complete the async callback method is called. As you mentioned the FileStream caches data as well, so this gives you a couple of situations for a read operation: 1) the data requested is in the cache buffer 2) there is not enough data in the cache buffer to satisfy the request. In the first case, the data will be read from the cache during BeginRead which will also call EndRead and then call the callback method asynchonously before returning. In effect, the call becomes synchronous. In the second case the output buffer is filled with the cache, and then the remainder is filled with an async ReadFile, but not necessarily for a multiple of the block size. Indeed, it just reads the number of bytes requested minus those that were provided by the cache. It seems to me that if you read *exactly* the cache size each time then you'll get better performance (because you'll get a short circuit to the native call to ReadFile and no excess will be cached). I suspect this is why you found that a buffer of 64K works and that other buffer sizes affect performance by so much. I don't think this has any effect. Anyway, file handles can only be bound to a single thread (remember, this happens for the native read to the file through BeginRead), so you can only make one call to BeginRead at a time for a particular FileStream object. Richard [/QUOTE]
Verification
Post reply
Home
Forums
Newsgroups
Microsoft DotNet
Microsoft Dot NET Framework
Disk file write performance
Top