In the past I have used the Binary File Access provided by VB6 using Open #x. Binary access is not supported by FSO (File System Object). I wanted to find out if file access using the Windows API was quicker than the Binary access. So I developed 2 similar test programs, one using VB6 Binary file access (IOFile2.vbp), and one using Windows API (IOFile1.vbp).
One should expect some variability between test runs, but I was having difficulty getting anything but zero ms times for both read and write, no matter what the file size was. After further research, I discovered that repeated reads and writes do not necessarily test disk access. Disk access is buffered (cached). To get any kind of result, I had to use FILE_FLAG_NO_BUFFERING instead of FILE_ATTRIBUTE_NORMAL. Even then you cannot count on getting accurate results, as some disk systems have their own built-in buffering (see: https://learn.microsoft.com/en-us/wi...file-buffering ). And I know of no way to disable buffering on Binary file access from VB6, so I never did get a valid comparison.
The 2 programs provided use normal disk access. To test without buffering in the API program (IOFile1.vbp), you will need to disable the current "fOpen" routine and enable the one below it in both cmdRead_Click & cmdWrite_Click. I took the liberty of renaming the "CreateFileA" function because most of the time the files are not just being created.
Either process will overwrite an existing file, but neither one will properly terminate the file should the new one be shorter in length. The original file length will be retained, and it is up to the program to determine that and delete the existing file before writing the newer shorter file.
As far as I can tell, the only reason to use the API is that there are many more options available. There is nothing really wrong with the VB6 routines. I have provided a few of the declarations that I did not use. "FlushFileBuffers" was provided, but did not seem to make much difference. I did not provide individual error reporting, as from my point of view, I was only interested that it either succeeded or not.
J.A. Coutts
Note: Adding Debug.Print statements will provide execution times, but will not measure file access.
One should expect some variability between test runs, but I was having difficulty getting anything but zero ms times for both read and write, no matter what the file size was. After further research, I discovered that repeated reads and writes do not necessarily test disk access. Disk access is buffered (cached). To get any kind of result, I had to use FILE_FLAG_NO_BUFFERING instead of FILE_ATTRIBUTE_NORMAL. Even then you cannot count on getting accurate results, as some disk systems have their own built-in buffering (see: https://learn.microsoft.com/en-us/wi...file-buffering ). And I know of no way to disable buffering on Binary file access from VB6, so I never did get a valid comparison.
The 2 programs provided use normal disk access. To test without buffering in the API program (IOFile1.vbp), you will need to disable the current "fOpen" routine and enable the one below it in both cmdRead_Click & cmdWrite_Click. I took the liberty of renaming the "CreateFileA" function because most of the time the files are not just being created.
Either process will overwrite an existing file, but neither one will properly terminate the file should the new one be shorter in length. The original file length will be retained, and it is up to the program to determine that and delete the existing file before writing the newer shorter file.
As far as I can tell, the only reason to use the API is that there are many more options available. There is nothing really wrong with the VB6 routines. I have provided a few of the declarations that I did not use. "FlushFileBuffers" was provided, but did not seem to make much difference. I did not provide individual error reporting, as from my point of view, I was only interested that it either succeeded or not.
J.A. Coutts
Note: Adding Debug.Print statements will provide execution times, but will not measure file access.