Printable View
Okay, here is what I have to do. Work with files. But the thing is, should I use API functions or just standard c functions for this?
And also, a question about it (which ever way I decide to go): I need to either read a certain file (for example: file.txt) or if it is not existing, I need to create the file (file.txt). How would I approach this? What functions?
Thanks! :D
The windows API file stuff don't *seem* to be as easy to use in the beginning. I'm still learning them all but they seem to be an overall better way of handling files the standard C
API functions are far superior. That is if speed is important to you.
CreateFile()Quote:
And also, a question about it (which ever way I decide to go): I need to either read a certain file (for example: file.txt) or if it is not existing, I need to create the file (file.txt). How would I approach this? What functions?
What do you base this statement on? Have you compared the speed differences between the two? I am curious about this, because I would believe that they would both be the same, as they both make use of the same low level interrupts.Quote:
Originally posted by FillYourBrain
API functions are far superior. That is if speed is important to you.
yes I have run speed trials on the C runtime vs system API. Window API on first access of the file takes about half the time to read. On following reads of the same file however, Windows API takes about 1/10th of the time to read. This is due to caching. Sorry to the "standards" purists. My heart goes out to you.
But how would I first check if the file already exists?Quote:
You need to read the MSDN on that function.
CreateFile(), despite it's misleading name, can open old files, check for existance, check for write access, create files, and even play with devices.
I'm sorry, but this boggles my mind... What form of caching does the Win32 API do that regular C functions do not do? Also, as evident by your wording, you are not speaking about reading in a single file in its entirety at once. Have you tested this? What are the conditions of your test when reading in the file segments at a time?Quote:
Originally posted by FillYourBrain
...Window API on first access of the file takes about half the time to read. On following reads of the same file however, Windows API takes about 1/10th of the time to read. This is due to caching...
I don't know about FillYourBrain, but in the compilers I've tested (GNU, Microsoft VC++, Borland C++) the C functions have simply been wrappers for the Windows API functions, and so using the API functions is marginally quicker than use the standard C library.
By using sensible buffers (64Kb reads for example), you can hardly tell the difference between them. It's only when you are reading such small quantities like a single byte at a time does the extra overhead show through.
There is also another advantage if you use advanced WinAPI functions. For example, you can use CreateFile(), CreateFileMapping(), and CreateViewOfFile() to memory-map a file. This allows the OS a lot of flexibility on when it actually performs disk access.
The latency of a disk is high, because it takes time to physically position the head and wait for the platter to spin into the right position. However, once the head is positioned, you can read a lot of sequential data very fast, because as the platter spins, the head simply moves over the data sequentially. For example, if you were to read 64K worth of data, one byte at a time, it would be vastly slower than reading the whole 64K chunk at once.
Reading byte-by-byte would look like:
-Position- -Wait- -Read 1 byte- -Position- -Wait- -Read 1 byte- -Position- -Wait- -Read 1 byte-, etc. A lot of wasted time.
Reading a block of data would look like:
-Position- -Wait- -Read 64 kbytes-
In general, by using the API functions, and by doing so in an intelligent way, you can read/write data in a much faster and more intelligent fashion. You can let the OS decide when to commit data to the disk, or when data needs to be read from the disk, instead of forcing reads or writes on every data access/change.
(As an aside, memory-mapped files are a great way to share data between processes).
:confused: Is the C runtime not its own DLL? Not sure about that. Regardless. My time trials were very extensive.Quote:
I don't know about FillYourBrain, but in the compilers I've tested (GNU, Microsoft VC++, Borland C++) the C functions have simply been wrappers for the Windows API functions, and so using the API functions is marginally quicker than use the standard C library.
large and small files, repetative opening and closing, repetative seeking, repetative small reads, repetative large reads. In all cases, the Windows function won out by substantial margins.
edit: The C runtime is in fact its own dll. crtdll.dll to be precise. Therefore unless you disassembled it and found it to be calling the API function then I question the above statement.
There's no need to disassemble anything, the full source code to the crtdll.dll is installed on my harddisk and in this code I can clearly see it call the Windows API CreateFile, WriteFile, etc functions.
regardless, do the time test yourself. You'll see what I'm talking about. Major difference.
I have, and I've not just used Microsoft VC++ either, I've also tested GNU C++ & Borland C++ (which don't use crtdll.dll). I only see a small improvement in speed between the C library and the Windows API. I wouldn't say that this small improvement in speed was worth risking the portability of the code.
If anyone has any testing code that others can compile to compare times, I would be willing to do so. I feel tempted to write my own test code, because this is bothering that the windows functions may be that much faster.
I still have to say that I would be very surprised to find out they are. FillYourBrain, are you positive the speed differences could not be attributed to some other factor? I fail to see why the windows OS would not perform the same caching features on the standard functions, as it does with the win32 api functions. Especially after _Elixia_ has stated that, aside from some overhead, they are, in fact, the same calls.
Windows 2000 VC++6. 6 or 7 months ago. Don't have the code anymore. I used fopen, CreateFile, fclose, CloseHandle, etc... GetTickCount() gives you the times before and after major repetition loops. There is a chance that NT is different than personal versions of windows. I don't know.
I really didn't get into this for a debate anyway. But on the topic of portability, true portability is impossible without sacrificing all of the unique features of a particular operating system. This is why Java is a "lowest common denominator" language. You can achieve portability more effectively with wrappers and emulating classes.
Just covering the obvious, but has anyone taken into account the binary/text issue.
WinApi functions are all binary where as the C lib functions, if in text mode, have to parse the entire string to find and replace '\n' with "\r\n". This would make a significant difference in speed.
Having a look at the source, write.c, this is done into a 1025 byte buffer which is written out using WriteFile every time it is fill. This would make a massive difference for larger writes.
It should be noted that we can mix and match to some extent:
http://msdn.microsoft.com/library/en..._osfhandle.asp
_osfhnd
I really didn't want to have to re-code this test but here it is for the unbelievers. My results were consistent with the old results I got. Very large margin of speed difference.
Please, run it. enjoy.
Code:#include <windows.h>
#include <iostream>
#include <stdio.h>
int main(void)
{
DWORD test1, test2, written;
struct _iobuf *file_runtime;
HANDLE file_api;
int i;
char *buf = new char[10000];
//Create the file
file_api = ::CreateFile("C:\\TestFile.dat", GENERIC_WRITE, NULL, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
::CloseHandle(file_api);
//OPEN and CLOSE tests.
//runtime
test1 = ::GetTickCount();
for(i=0; i < 10000; i++)
{
file_runtime = fopen("C:\\TestFile.dat", "rb");
fclose(file_runtime);
}
test2 = ::GetTickCount();
std::cout << "OPEN/CLOSE runtime " << (int)(test2-test1) << std::endl;
//API
test1 = ::GetTickCount();
for(i=0; i < 10000; i++)
{
file_api = ::CreateFile("C:\\TestFile.dat", GENERIC_READ, NULL, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
::CloseHandle(file_api);
}
test2 = ::GetTickCount();
std::cout << "OPEN/CLOSE W32 API " << (int)(test2-test1) << std::endl;
//LARGE WRITE tests
//runtime
test1 = ::GetTickCount();
file_runtime = fopen("C:\\TestFile.dat", "wb");
for(i=0; i < 10000; i++)
{
fwrite(buf, 10000, 1, file_runtime);
fseek(file_runtime, 0, SEEK_SET);
}
fclose(file_runtime);
test2 = ::GetTickCount();
std::cout << "LARGE WRITE runtime " << (int)(test2-test1) << std::endl;
//API
test1 = ::GetTickCount();
file_api = ::CreateFile("C:\\TestFile.dat", GENERIC_WRITE, NULL, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
for(i=0; i < 10000; i++)
{
::WriteFile(file_api, buf, 10000, &written, NULL);
::SetFilePointer(file_api, 0, 0, FILE_BEGIN);
}
::CloseHandle(file_api);
test2 = ::GetTickCount();
std::cout << "LARGE WRITE W32 API " << (int)(test2-test1) << std::endl;
//SMALL WRITE tests
//runtime
test1 = ::GetTickCount();
file_runtime = fopen("C:\\TestFile.dat", "wb");
for(i=0; i < 100000; i++)
{
fwrite(buf, 1, 1, file_runtime);
fseek(file_runtime, 0, SEEK_SET);
}
fclose(file_runtime);
test2 = ::GetTickCount();
std::cout << "SMALL WRITE runtime " << (int)(test2-test1) << std::endl;
//API
test1 = ::GetTickCount();
file_api = ::CreateFile("C:\\TestFile.dat", GENERIC_WRITE, NULL, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
for(i=0; i < 100000; i++)
{
::WriteFile(file_api, buf, 1, &written, NULL);
::SetFilePointer(file_api, 0, 0, FILE_BEGIN);
}
::CloseHandle(file_api);
test2 = ::GetTickCount();
std::cout << "SMALL WRITE W32 API " << (int)(test2-test1) << std::endl;
//LARGE READ
//runtime
test1 = ::GetTickCount();
file_runtime = fopen("C:\\TestFile.dat", "rb");
for(i=0; i < 10000; i++)
{
fread(buf, 10000, 1, file_runtime);
fseek(file_runtime, 0, SEEK_SET);
}
fclose(file_runtime);
test2 = ::GetTickCount();
std::cout << "LARGE READ runtime " << (int)(test2-test1) << std::endl;
// API
test1 = ::GetTickCount();
file_api = ::CreateFile("C:\\TestFile.dat", GENERIC_READ, NULL, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
for(i=0; i < 10000; i++)
{
::ReadFile(file_api, buf, 10000, &written, NULL);
::SetFilePointer(file_api, 0, 0, FILE_BEGIN);
}
::CloseHandle(file_api);
test2 = ::GetTickCount();
std::cout << "LARGE READ W32 API " << (int)(test2-test1) << std::endl;
//SMALL READ
//runtime
test1 = ::GetTickCount();
file_runtime = fopen("C:\\TestFile.dat", "rb");
for(i=0; i < 10000; i++)
{
fread(buf, 1, 1, file_runtime);
fseek(file_runtime, 0, SEEK_SET);
}
fclose(file_runtime);
test2 = ::GetTickCount();
std::cout << "SMALL READ runtime " << (int)(test2-test1) << std::endl;
// API
test1 = ::GetTickCount();
file_api = ::CreateFile("C:\\TestFile.dat", GENERIC_READ, NULL, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
for(i=0; i < 10000; i++)
{
::ReadFile(file_api, buf, 1, &written, NULL);
::SetFilePointer(file_api, 0, 0, FILE_BEGIN);
}
::CloseHandle(file_api);
test2 = ::GetTickCount();
std::cout << "SMALL READ W32 API " << (int)(test2-test1) << std::endl;
::DeleteFile("C:\\TestFile.dat");
delete [] buf;
return 0;
}
Thanks for taking the time to make your code available. I noticed a problem with the code. You basically determine that a 'small read/write' is that of 1 byte, and a 'large read/write' is 10,000 bytes. I do not think this is proper, as no one reads files in a byte at a time. You cannot even instruct hard disks (at low level) to read only 1 byte into memory. (As a result of this program's method, I should clarify that my argument is from the perspective of a proper programmer using proper programming techniques, as I do not care which method results in reading a file faster 1 byte at a time, as it is something no programmer who knows what he is doing would attempt to do.) If you wish to access such small amounts of data from a file, you can simply read it all into memory first (and thus it becomes a large read/write problem). If you have multiple small files, they should be combined into one larger file. A proper program should never have to read in a file this small (with the obvious exceptions of maybe .INI or .CFG files - in either case, it is a one shot deal, so speed is not a concern).
I personally think at least several kilobytes would be considered a 'small read/write', and that 'large read/writes' would be on the order of megabytes. In any case, I changed your code a bit, and tried it with both your parameters and mine:
FillYourBrain parameters:
Again, I think testing a 1 byte read/write is pretty much useless. So, I made the small read/write 10,000 bytes, and the large 1,000,000 bytes:Code:Large read/writes ues a buffer of 10000 bytes.
Small read/writes ues a buffer of 1 bytes.
OPEN/CLOSE runtime 39347
OPEN/CLOSE W32 API 35361
Win32 API takes 89% the time of the C runtime library.
LARGE WRITE runtime 7941
LARGE WRITE W32 API 5218
Win32 API takes 65% the time of the C runtime library.
SMALL WRITE runtime 2093
SMALL WRITE W32 API 1903
Win32 API takes 90% the time of the C runtime library.
LARGE READ runtime 2523
LARGE READ W32 API 1502
Win32 API takes 59% the time of the C runtime library.
SMALL READ runtime 1643
SMALL READ W32 API 1392
Win32 API takes 84% the time of the C runtime library.
Jason's parameters:
I have to admit I am still very surprised at the results. Not as bad as 10% of the speed that FillYourBrain originally claimed (...Window API on first access of the file takes about half the time to read. On following reads of the same file however, Windows API takes about 1/10th of the time to read...), but still, 53% is only half speed.Code:Large read/writes ues a buffer of 1000000 bytes.
Small read/writes ues a buffer of 10000 bytes.
OPEN/CLOSE runtime 193068
OPEN/CLOSE W32 API 177655
Win32 API takes 92% the time of the C runtime library.
LARGE WRITE runtime 134313
LARGE WRITE W32 API 134324
Win32 API takes 100% the time of the C runtime library
SMALL WRITE runtime 83570
SMALL WRITE W32 API 55870
Win32 API takes 66% the time of the C runtime library.
LARGE READ runtime 180490
LARGE READ W32 API 95807
Win32 API takes 53% the time of the C runtime library.
SMALL READ runtime 64373
SMALL READ W32 API 50683
Win32 API takes 78% the time of the C runtime library.
I guess I have to question the method the program is using to test this speed - it is continually accessing the same file. This is unlike (most) real world applications - the file is normally read once into memory. Isn't it awfully strange that writing is the same speed, and reading is only 1/2 speed? What do you guys think?
Here's my revision to the program, in case you are interested:
Code:// Thread URL: http://cboard.cprogramming.com/showt...5&pagenumber=2
// Program original by: FillYourBrain
// Modified slightly by: Jason Doucette (http://www.jasondoucette.com/)
// Purpose: testing C functions vs Win32 API functions, for speed of file accessing
#include <windows.h>
#include <iostream>
#include <stdio.h>
/*
// FillYourBrain
#define NUM_OPENCLOSE 1000000
#define NUM_LARGEWRITE 1000000
#define NUM_SMALLWRITE 1000000
#define NUM_LARGEREAD 1000000
#define NUM_SMALLREAD 1000000
#define BUFFERSIZE 10000
#define SMALLSIZE 1
*/
// Jason
#define NUM_OPENCLOSE 5000000
#define NUM_LARGEWRITE 10000
#define NUM_SMALLWRITE 10000000
#define NUM_LARGEREAD 2000000
#define NUM_SMALLREAD 10000000
#define BUFFERSIZE 1000000
#define SMALLSIZE 10000
int main(void)
{
DWORD test1, test2, written;
int et1, et2;
struct _iobuf *file_runtime;
HANDLE file_api;
int i;
std::cout << "Large read/writes ues a buffer of " << BUFFERSIZE << " bytes." << std::endl;
std::cout << "Small read/writes ues a buffer of " << SMALLSIZE << " bytes." << std::endl;
std::cout << std::endl;
char *buf = new char[BUFFERSIZE];
//Create the file
file_api = ::CreateFile("C:\\TestFile.dat",
GENERIC_WRITE, NULL, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
::CloseHandle(file_api);
//--------------------------------------------------------
//OPEN and CLOSE tests.
//runtime
test1 = ::GetTickCount();
for(i=0; i < NUM_OPENCLOSE; i++)
{
file_runtime = fopen("C:\\TestFile.dat", "rb");
fclose(file_runtime);
}
test2 = ::GetTickCount();
et1 = test2-test1;
std::cout << "OPEN/CLOSE runtime " << et1 << std::endl;
//API
test1 = ::GetTickCount();
for(i=0; i < NUM_OPENCLOSE; i++)
{
file_api = ::CreateFile("C:\\TestFile.dat",
GENERIC_READ, NULL, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
::CloseHandle(file_api);
}
test2 = ::GetTickCount();
et2 = test2-test1;
std::cout << "OPEN/CLOSE W32 API " << et2 << std::endl;
std::cout << "Win32 API takes " << et2 * 100 / et1
<< "% the time of the C runtime library." << std::endl;
std::cout << std::endl;
//--------------------------------------------------------
//LARGE WRITE tests
//runtime
test1 = ::GetTickCount();
file_runtime = fopen("C:\\TestFile.dat", "wb");
for(i=0; i < NUM_LARGEWRITE; i++)
{
fwrite(buf, BUFFERSIZE, 1, file_runtime);
fseek(file_runtime, 0, SEEK_SET);
}
fclose(file_runtime);
test2 = ::GetTickCount();
et1 = test2-test1;
std::cout << "LARGE WRITE runtime " << et1 << std::endl;
//API
test1 = ::GetTickCount();
file_api = ::CreateFile("C:\\TestFile.dat",
GENERIC_WRITE, NULL, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
for(i=0; i < NUM_LARGEWRITE; i++)
{
::WriteFile(file_api, buf, BUFFERSIZE, &written, NULL);
::SetFilePointer(file_api, 0, 0, FILE_BEGIN);
}
::CloseHandle(file_api);
test2 = ::GetTickCount();
et2 = test2-test1;
std::cout << "LARGE WRITE W32 API " << et2 << std::endl;
std::cout << "Win32 API takes " << et2 * 100 / et1
<< "% the time of the C runtime library." << std::endl;
std::cout << std::endl;
//--------------------------------------------------------
//SMALL WRITE tests
//runtime
test1 = ::GetTickCount();
file_runtime = fopen("C:\\TestFile.dat", "wb");
for(i=0; i < NUM_SMALLWRITE; i++)
{
fwrite(buf, SMALLSIZE, 1, file_runtime);
fseek(file_runtime, 0, SEEK_SET);
}
fclose(file_runtime);
test2 = ::GetTickCount();
et1 = test2-test1;
std::cout << "SMALL WRITE runtime " << et1 << std::endl;
//API
test1 = ::GetTickCount();
file_api = ::CreateFile("C:\\TestFile.dat",
GENERIC_WRITE, NULL, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
for(i=0; i < NUM_SMALLWRITE; i++)
{
::WriteFile(file_api, buf, SMALLSIZE, &written, NULL);
::SetFilePointer(file_api, 0, 0, FILE_BEGIN);
}
::CloseHandle(file_api);
test2 = ::GetTickCount();
et2 = test2-test1;
std::cout << "SMALL WRITE W32 API " << et2 << std::endl;
std::cout << "Win32 API takes " << et2 * 100 / et1
<< "% the time of the C runtime library." << std::endl;
std::cout << std::endl;
//--------------------------------------------------------
//LARGE READ
//runtime
test1 = ::GetTickCount();
file_runtime = fopen("C:\\TestFile.dat", "rb");
for(i=0; i < NUM_LARGEREAD; i++)
{
fread(buf, BUFFERSIZE, 1, file_runtime);
fseek(file_runtime, 0, SEEK_SET);
}
fclose(file_runtime);
test2 = ::GetTickCount();
et1 = test2-test1;
std::cout << "LARGE READ runtime " << et1 << std::endl;
// API
test1 = ::GetTickCount();
file_api = ::CreateFile("C:\\TestFile.dat",
GENERIC_READ, NULL, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
for(i=0; i < NUM_LARGEREAD; i++)
{
::ReadFile(file_api, buf, BUFFERSIZE, &written, NULL);
::SetFilePointer(file_api, 0, 0, FILE_BEGIN);
}
::CloseHandle(file_api);
test2 = ::GetTickCount();
et2 = test2-test1;
std::cout << "LARGE READ W32 API " << et2 << std::endl;
std::cout << "Win32 API takes " << et2 * 100 / et1
<< "% the time of the C runtime library." << std::endl;
std::cout << std::endl;
//--------------------------------------------------------
//SMALL READ
//runtime
test1 = ::GetTickCount();
file_runtime = fopen("C:\\TestFile.dat", "rb");
for(i=0; i < NUM_SMALLREAD; i++)
{
fread(buf, SMALLSIZE, 1, file_runtime);
fseek(file_runtime, 0, SEEK_SET);
}
fclose(file_runtime);
test2 = ::GetTickCount();
et1 = test2-test1;
std::cout << "SMALL READ runtime " << et1 << std::endl;
// API
test1 = ::GetTickCount();
file_api = ::CreateFile("C:\\TestFile.dat",
GENERIC_READ, NULL, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
for(i=0; i < NUM_SMALLREAD; i++)
{
::ReadFile(file_api, buf, SMALLSIZE, &written, NULL);
::SetFilePointer(file_api, 0, 0, FILE_BEGIN);
}
::CloseHandle(file_api);
test2 = ::GetTickCount();
et2 = test2-test1;
std::cout << "SMALL READ W32 API " << et2 << std::endl;
std::cout << "Win32 API takes " << et2 * 100 / et1
<< "% the time of the C runtime library." << std::endl;
std::cout << std::endl;
//--------------------------------------------------------
// clean up
::DeleteFile("C:\\TestFile.dat");
delete [] buf;
return(0);
}
point one: yes, I guess my original figures were exaggerated. Oh well. Point still stands. The difference is dramatic nonetheless.
point2: I threw that test up there very quickly. the choice of read size is something you can mess with. but indeed you should mess with it and see the results.
I'm glad you took the time to try it out.
edit:
And as far as reading multiple files.... You're going to have to make that edit in the program. It starts to get too elaborate for this purpose as far as I'm concerned.
The point was only to show that it is clearly faster.
The problem is that the test only shows one thing - that it is clearly faster for reading the same file over and over again. This is not a real world situation.Quote:
Originally posted by FillYourBrain
And as far as reading multiple files.... You're going to have to make that edit in the program. It starts to get too elaborate for this purpose as far as I'm concerned.
The point was only to show that it is clearly faster.
You say that reading multiple files gets "too elaborate for this purpose", but I believe that reading multiple files (or doing some other method - does anyone else have any ideas?) is the only proper way of testing this. Anything simplier, like the method you have chosen, does not replicate a real world situation. Your test only shows that if you choose not to cache your files into memory yourself (which is rather foolish, but this information may be of interest to amateur programmers who choose not to do such things), then the win32 api functions are twice as fast as the runtime functions when reading from the same file in the future. Again, the point is that this simply does not happen in real world applications.
Also, as a hunch, I modified the small read/write size to be closer to a multiple of 32,768 (I am using NTFS), and the speeds have noticeably improved. I thought you guys may be interested:
Code:Large read/writes ues a buffer of 1000000 bytes.
Small read/writes ues a buffer of 65000 bytes.
OPEN/CLOSE runtime 20279
OPEN/CLOSE W32 API 17916
Win32 API takes 88% the time of the C runtime library.
LARGE WRITE runtime 13499
LARGE WRITE W32 API 13199
Win32 API takes 97% the time of the C runtime library.
SMALL WRITE runtime 47849
SMALL WRITE W32 API 45125
Win32 API takes 94% the time of the C runtime library.
LARGE READ runtime 27139
LARGE READ W32 API 18076
Win32 API takes 66% the time of the C runtime library.
SMALL READ runtime 45435
SMALL READ W32 API 43803
Win32 API takes 96% the time of the C runtime library.
This is a generalization. There are plenty of real world situations that work off of a single file and seek around the file. Most commercial software works off of a single file, and based on my experience (monitoring disk reads) most do not cache the entire file in memory. There is no worse way to waste memory than to cache huge files in memory.Quote:
Originally posted by JasonD
The problem is that the test only shows one thing - that it is clearly faster for reading the same file over and over again. This is not a real world situation.
See Above.Quote:
Originally posted by JasonD
You say that reading multiple files gets "too elaborate for this purpose", but I believe that reading multiple files (or doing some other method - does anyone else have any ideas?) is the only proper way of testing this. Anything simplier, like the method you have chosen, does not replicate a real world situation.
wasting memory is an amature programmer tendency as well. Seeking around a file is a perfectly legitimate way of doing things. I dare you to write a database app that works any other way!Quote:
Originally posted by JasonD
Your test only shows that if you choose not to cache your files into memory yourself (which is rather foolish, but this information may be of interest to amateur programmers who choose not to do such things)
real world is something I know my share about. And I have to disagree with you 100%. The norm is most certainly not what you are saying. And even if it were, write a test that does that. I have very little doubt of the results.Quote:
Originally posted by JasonD
, then the win32 api functions are twice as fast as the runtime functions when reading from the same file in the future. Again, the point is that this simply does not happen in real world applications.
try 700 megabyte ISO files. How about a series of them. Let's see you come up with tests on that caching the whole thing in memory on a system with 64 meg of RAM.
edit: And I'm a little confused by the fact that you're arguing. Thusfar I've completely backed up my claims. If you want to show an exception, then by all means back it up.
I think there is a confusion, and I will attempt to explain my perspective in more detail:
I can understand that this may occur for a database program used by multiple users, since you may have to write the data back to the database in case others wish to access it. But, the fact that the database is changing so rapidly means the memory caching will be ineffective. In each other real world case that you mentioned, the file that is being read from is being read from different portions of the file. They are being accessed continuously, but never the same area over and over again. Your program continually reads the same portion of the same file.
If you ever need to do what your test shows (i.e. reading the same portion of the file over and over again), this portion of the file should be cached manually into memory. This is not wasting memory like an amateur - it is what any professional programmer would do. Of course, the limit on how much you can do this depends on the file portion's size. As this size increases, there will be a limit reached in which you have no option but to manually cache a smaller section of it, or let Windows do its own memory caching (like your test program). At this point, the performance of either case is going to drop drastically, as there is no more RAM for you (or Windows) to cache the entire frequently accessed file.
Ok, this is a good example of a real-world application to explain my point. Your original test program reads the same file over and over again. This example program requires you to read a new 64 MB section of the file each time (of course you can't cache the whole thing - that was never my point). The difference is that each new section is uncached in this real-world app, and in your test program the section is cached after the first read.Quote:
Originally posted by FillYourBrain
try 700 megabyte ISO files. How about a series of them. Let's see you come up with tests on that caching the whole thing in memory on a system with 64 meg of RAM.
Please understand that I am not arguing that the win32 api functions are not faster - I am arguing that the test does not prove anything for a real world application (as most programs never access the files in the way that your test does). Now, if windows can anticipate that a future read may be done on the next chunk in the file (i know some caches do this), whereas the C runtime code does not, then a test on reading such a file in the sequential way we've just described would prove that the win32 api is faster in a way that most applications deal with files.
I hope that I have made myself clearer.
EDIT: Perhaps a program that does the following would be a better test: Create a file that is much larger than available RAM, and then continually access random portions of the file. Since the file is much larger than available RAM, and each portion of the file has just as much of a chance to be accessed as any other, we will not do our own memory cache management, and let Windows take care of it. I believe this test would prove a lot. Perhaps with the same results as your test.
if the test proves nothing (which I doubt) provide a better test.
and my comments were only because of your blanket statement about reading small pieces of a file being non-real-world.
Fact remains. best test so far is what I have provided and it leaves us with moderatedly conclusive results.
Yes, your test is the best test so far, but it is the only test so far. I was simply pointing out that it may not prove as much as it appears due to its method. That is why I mentioned that perhaps someone may have a better alternative.Quote:
Originally posted by FillYourBrain
if the test proves nothing (which I doubt) provide a better test.
and my comments were only because of your blanket statement about reading small pieces of a file being non-real-world.
Fact remains. best test so far is what I have provided and it leaves us with moderatedly conclusive results.
I just edited my post above, as you were writing your reply, with a test that may be more real-world like. Let me know what you think about it.
I would also, actually, be interested in the differences of file accessing when each file needs only be accessed once - much like a lot of real-world applications, such as reading an .ISO file. One generalized test cannot show the differences of all possibilities. If I have time later today, I'll throw a couple of these tests together.
by the way, if we can prove that the API is faster than the runtime at least some of the time and the API is slower than the runtime none of the time then I think its fair to say that a programmer concerned with speed would have to use the API for a windows based app. The real challenge for you I guess is to show an example where the API is actually slower. Because with the data so far, performing the same isn't good enough to make a case for using C runtime calls. I say this while stressing that portability can be better obtained by using inline wrappers to system calls than it can through using the over glorified "standard".
Good point. I do agree that using wrappers is the best for portability. I am in the middle of developing a product at the moment to be as portable as possible, and was about to write some image loading routines when I came upon this thread. I am in the middle of trying to decide something for the following case:
If the C runtime library is around 98% of the speed of the win32 api (in the specific case of whatever your program does with its files, which I believe it will be for my case) should I use it? Even with wrappers, when it comes time to port, it is one more section of code you needn't rewrite. What do you think?
my classes library typically makes no assumptions of external calls. templates, macros, and inline functions wrap most everything so that I can write completely portable code using the implementations of the library for each system (only linux and windows at the moment and linux is just getting underway)
My feeling is that even if they are the same exact call on both systems it may still be better to wrap it. But then I like to make these things objects anyway so they are wrapped already.
side note: I don't know if you've ever seen the IJG jpeg library or the gzip code but they both use macros to wrap the reading and writing. And for windows, they use API calls!!
I was in the middle of creating a test program, and when I was writing the win32 API version, I decided to look more into the CreateFile function. For the dwFlagsAndAttributes parameter, you can use:
FILE_FLAG_RANDOM_ACCESS
Indicates that the file is accessed randomly. The system can use this as a hint to optimize file caching.
FILE_FLAG_SEQUENTIAL_SCAN
Indicates that the file is to be accessed sequentially from beginning to end. The system can use this as a hint to optimize file caching. If an application moves the file pointer for random access, optimum caching may not occur; however, correct operation is still guaranteed.
Specifying this flag can increase performance for applications that read large files using sequential access. Performance gains can be even more noticeable for applications that read large files mostly sequentially, but occasionally skip over small ranges of bytes.
It looks like the two methods that I was going to use for my test program to emulate real-world behaviour each have specific settings within CreateFile to optimize the caching... I did not finish my program, I had to leave my office right as I found out this information. I just thought I would write now, and let you know. If you use the Win32 API for the specific purpose of random or sequential access, then these settings should be specified as part of the program. I will try them out tomorrow, and see.
Don't forget that "fopen" also has these flags, although I don't think they are in the standard, but are specific to certain compilers (which kinda goes against these tests, but anyway).
For example, in MSVC++, the following are the same:
FILE_FLAG_RANDOM_ACCESS in CreateFile &
"rR" in fopen.
FILE_FLAG_SEQUENTIAL_SCAN in CreateFile &
"rS" in fopen.
Although these flags are mentioned as compiler specific, I wonder how many compilers actually support them? Since bad characters are normally ignored, by placing them at the end of the format string, it should increase speed under compilers that support it and be ignored on ones that dont :)
BTW, It seems that FILE_FLAG_RANDOM_ACCESS simply causes Windows to not do read-ahead caching, but to just cache what you read instead and hold it for a while, whilst FILE_FLAG_SEQUENTIAL_SCAN fully enables read-ahead caching, and throws out earlier information quicker (as it assumes you'll not need it anymore).
EDIT: I'm not sure what happens when neither of these flags are specifies (not tested)
So does paintlib -- I wrote some of the Win32-specific code, in fact. It uses memory-mapped file I/O on Win32 systems.Quote:
Originally posted by FillYourBrain
side note: I don't know if you've ever seen the IJG jpeg library or the gzip code but they both use macros to wrap the reading and writing. And for windows, they use API calls!!
Slightly off-topic question, but when you do your memory-mapped I/O, how do you guarantee that you are still within valid file memory? Do you simply wrap all memory accesses using the size of the file, ask windows via IsBadReadPtr() or similar, or simply rely on the fact that you'll not get bad pointers?Quote:
Originally posted by Cat
So does paintlib -- I wrote some of the Win32-specific code, in fact. It uses memory-mapped file I/O on Win32 systems.
Because the file class is derived from an ABC, the file I/O is hidden behind an abstraction. The size of the source or sink is contained within the class. For output, where the precise file length will not be known, the library overallocates for a worst-case scenario and truncates the file at the end.Quote:
Originally posted by _Elixia_
Slightly off-topic question, but when you do your memory-mapped I/O, how do you guarantee that you are still within valid file memory? Do you simply wrap all memory accesses using the size of the file, ask windows via IsBadReadPtr() or similar, or simply rely on the fact that you'll not get bad pointers?
Thanks for the information. I could not find this information on the MSDN page for fopen. I was wondering where you found it? I will try them out in my test program.Quote:
Originally posted by _Elixia_
For example, in MSVC++, the following are the same:
FILE_FLAG_RANDOM_ACCESS in CreateFile &
"rR" in fopen.
FILE_FLAG_SEQUENTIAL_SCAN in CreateFile &
"rS" in fopen.
Although these flags are mentioned as compiler specific, I wonder how many compilers actually support them? Since bad characters are normally ignored, by placing them at the end of the format string, it should increase speed under compilers that support it and be ignored on ones that dont :)
I did find them specified on a website. Although I can't remember the website it was on, it was certainly not in the Microsoft domain.
Anyway, these flags are present in the sources of the Microsoft C runtime library:
D:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\crt\src\_open.c (_openfile())
called from:
D:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\crt\src\fopen.c (fopen())
I do find it strange that they are documented on a third party website, but not on Microsoft's website, who are the creator of this library.
I have made a program to test sequential access speeds:
3 different tests are perform for the C runtime library, and 3 more for the Win32 API. The 3 tests for each are as follows:
1. regular setting
2. sequential read setting
3. random access setting
(i.e "rb", "rbS", "rbR" for C runtime,
0, FILE_FLAG_SEQUENTIAL_SCAN, FILE_FLAG_RANDOM_ACCESS for Win32 API).
Each of the total 6 tests uses a different file, 65 MB in size, and is read into a 1 MB buffer sequentially. Each test is performed one after the other, and then the whole process is repeated. I have 512 MB of RAM on my system, so all 6 files could be cached in memory at the same time, if desired by the OS. The results are below:
You'll notice the slower times for the first rep, and you'll notice that the sequential read setting does get rid of the cached data, assuming that you will not be reading it again (as shown by the slow speeds after the first rep), where as the other two tests do not (they are much faster after the first rep, as it is still cached). The speeds for C runtime vs Win32 API are about the same, the Win32 API being slightly faster (the clock is accuracy to only 10 ms).Code:test: rb rbS rbR 0 SEQ RAND
Rep # 0: 3595 3565 1593 3815 3195 1532
Rep # 1: 280 3285 260 261 2824 260
Rep # 2: 281 2483 251 280 2554 250
Rep # 3: 270 2434 250 281 2583 261
Rep # 4: 270 2133 261 270 2514 260
Rep # 5: 280 2274 260 260 2514 251
Rep # 6: 260 2253 261 270 2534 260
Rep # 7: 270 2234 260 270 3075 260
Rep # 8: 280 2835 260 270 2814 261
Rep # 9: 270 2804 251 280 2774 250
Rep #10: 271 2824 260 270 3214 251
Rep #11: 280 2764 260 271 2814 260
Rep #12: 280 2794 261 270 2424 260
Rep #13: 271 2824 260 270 1853 260
Rep #14: 271 2053 260 271 1852 261
Rep #15: 280 2774 260 271 1862 251
Rep #16: 270 2804 261 280 1963 260
Rep #17: 271 3024 260 271 1822 261
Rep #18: 270 2814 261 270 1913 260
Rep #19: 270 2033 251 280 2734 260
Rep #20: 271 2333 251 280 2804 260
Rep #21: 261 1883 260 270 2894 261
Rep #22: 280 2714 261 270 3034 261
Rep #23: 280 1673 260 280 2764 261
Rep #24: 270 2814 270 271 2864 260
Rep #25: 261 3014 260 271 2824 260
Rep #26: 281 2894 260 271 2663 251
Rep #27: 260 2894 261 270 2744 260
Rep #28: 271 1612 261 270 2694 260
Rep #29: 271 2814 260 270 2754 261
Rep #30: 270 2774 261 270 2834 260
Rep #31: 281 2824 260 281 2784 260
-----------------------------------------------------------
avg: 376 2601 300 382 2609 298
The surprising thing is that the random access (for the first rep - the one that actually matters) is almost twice as fast as the sequential access - even though these files are being accessed sequentially. Why? I have no idea... It's hard to get an accurate test because Windows is already trying to cache the files from previous runs. This test was run after a test on 650 MB files, to ensure there is no possible way these 6 files were cached prior to running the test.
If anyone wishes to run my program on their system, let me know, and i'll make it available. I will post results re: random access later.
My conclusions thus far, given that the win32 api appears to be at least slightly faster in all occasions, is that you should use the win32 api for file access. I agree that these should be under wrappers for portability. Despite the fact that the C functions are portable as is, with wrappers, the Win32 API functions will only require a few lines of code to change during porting, which is really not a big deal, at all.
Here is the same test on 6 files that are 650 MB, all read into the same 1MB buffer, on a WinXP machine with 512 MB of RAM:
Code:test: rb rbS rbR 0 SEQ RAND
Rep # 1: 37794 32547 17205 37884 28341 15893
Rep # 2: 47248 29823 17215 33378 28981 21071
Rep # 3: 37704 28671 24756 46526 17416 15722
Rep # 4: 37534 28561 22563 37534 27900 15442
Rep # 5: 59135 18567 16393 33629 27820 15402
Rep # 6: 45155 28721 16414 29542 44264 19969
Rep # 7: 35270 28662 16483 53237 28070 15683
Rep # 8: 34660 46517 16654 38445 27920 15643
Rep # 9: 48179 29322 16283 30594 27790 29843
Rep #10: 27420 31485 16594 37043 42481 16304
Rep #11: 34179 28371 15953 52255 28591 20139
Rep #12: 37033 25727 17686 29302 28681 26729
Rep #13: 53436 32587 16644 38826 24796 16664
Rep #14: 32867 28391 16343 60827 28701 15833
Rep #15: 34139 40519 20088 37995 23564 16123
Rep #16: 58585 20138 16563 37174 28280 15492
Rep #17: 52065 29172 17335 35731 28731 15983
Rep #18: 37214 28441 16213 49932 35992 15702
Rep #19: 37214 38896 16734 31345 24135 15562
Rep #20: 54629 30684 21731 38325 28291 20890
Rep #21: 35781 28612 16684 60917 20870 15963
Rep #22: 44965 28771 16484 54639 28251 15502
Rep #23: 37955 25857 16443 35922 35471 15823
Rep #24: 64513 28831 16123 34910 30955 16384
Rep #25: 37624 35991 16624 47829 28051 15732
Rep #26: 36653 39737 16263 37434 27720 15503
Rep #27: 57843 20099 16513 31476 39026 18196
Rep #28: 33889 28501 16193 61278 28842 15582
Rep #29: 38535 39257 17755 33618 27880 16073
Rep #30: 52716 31836 16053 35291 28050 21120
Rep #31: 34250 28631 17675 33368 58344 24015
Rep #32: 35311 28741 32367 31445 27760 15552
---------------------------------------------------------
avg: 42234 30333 17844 40239 30061 17672
I modified the same program to try random access. Instead reading in the 65 MB file sequentially, it reads 1 MB from it, at random places, 512x in a row. It tries all 3 settings for both the C runtime and Win32 API. Here are the results:
As you can see, the setting for random access is the best, but only slightly better than the regular setting. The sequential setting obviously dumps the cache, assuming that it will not need to be accessed again.Code:test: rb rbS rbR 0 SEQ RAND
Rep # 1: 4407 13880 4236 4066 12287 3926
Rep # 2: 2083 10165 1992 2093 10866 2043
Rep # 3: 2163 14371 1993 2103 11116 1993
Rep # 4: 2083 13619 2013 2093 9694 1993
Rep # 5: 2093 9413 2003 2103 10285 1993
Rep # 6: 2093 10996 1993 2103 10805 1983
Rep # 7: 2113 10695 1993 2093 10916 2003
Rep # 8: 2113 11967 2003 2113 9183 2003
Rep # 9: 2093 9584 2003 2113 9373 2003
Rep #10: 2093 10025 2003 2103 9303 2003
Rep #11: 2093 11276 2003 2113 10555 2003
Rep #12: 2103 9093 2013 2103 9944 1983
Rep #13: 2113 9794 2003 2113 9254 2002
Rep #14: 2103 9074 2002 2093 10906 1993
Rep #15: 2113 9023 2003 2103 10976 2003
Rep #16: 2113 9834 2013 2093 10084 2003
Rep #17: 2103 9544 2003 2103 9493 1993
Rep #18: 2113 10005 2002 2094 9523 2003
Rep #19: 2103 9834 1993 2113 8933 2003
Rep #20: 2103 9754 2063 2143 10665 2003
Rep #21: 2103 11807 2003 2103 9784 1993
Rep #22: 2113 9734 2003 2123 8923 1993
Rep #23: 2103 10495 2013 2103 9303 2003
Rep #24: 2113 10926 2013 2093 10495 1993
Rep #25: 2113 10104 2003 2123 10255 2003
Rep #26: 2113 9423 2003 2113 9854 2013
Rep #27: 2113 9744 2003 2113 10375 1993
Rep #28: 2123 9284 2012 2103 10045 2003
Rep #29: 2153 17455 2013 2113 8893 2023
Rep #30: 2113 10565 2023 2113 10184 2013
Rep #31: 2123 10606 2012 2124 9063 2002
Rep #32: 2124 9012 2013 2113 10325 2003
-----------------------------------------------------------
avg: 2181 10659 2076 2168 10051 2061
Nice work Jason! I know it can be done easily enough, but could you include %-age speed increase on each line, which is the result of using Win32 API over C-api?
Yes, I will add this, and re-run the program. I will post the results later today (I run the tests over breaks when I am not at the computer).
I should have done this beforehand, but I guess I thought the numbers were so close that it did not really matter. I hope that everyone now understands the difference of the original test (re-reading the same portion of the same file over and over again) compared to these tests (reading an entire file once, sequentially, and randomly accessing small portions of a very large file). I believe these tests are far more accurate as an emulation of most real-world applications.
wow, you're really putting some time into this. Good work. I kicked out my test in about 10 minutes which is why it isn't very complete. It's only that there's only so much time I'm willing to devote to testing. Still, your tests seem consistent with the original. This is good.
While I still dispute the un- "real world" - edness of reading a single file many times, it is good to have more information now. There are only so many applications that read more than one file at a time. File servers obviously do. A good many do not. Walk through the programs on your system. MS word, MS excel, Photoshop, etc... aside from ini or registry reading, these mostly work off of a single file. Scanning, writing, reading from that file is their job. The software I work on at my job certainly spends its time in one or two files at the same time. I can't see your perspective of what is real world.
To be honest, I am spending more time on this than I first desired, so I understand why you made your program in 10 minutes... But, your results bothered me enough that I had to make my program. I truly believe your program does not emulate any professional real world program, and that my program only emulates most real-world programs in 2 specific cases:
1. when reading a file sequentially - a one shot deal.
2. random access to a file larger than available RAM.
My program should be improved to emulate a large file that may or may not fit in available RAM, which is read and written to. The basis of these above conclusions is as follows:
I agree that most programs work on a single large file. It is my hypothesis that these programs do not read, and re-read the same section of unchanged data multiple times, like your program, and mine, both do. I would think that in these cases, these sections of the file are manually cached to memory. If these sections need to be accessed again, the program should use its memory copy, not read from the file again. If these sections need to be changed, and then the program needs to access the new changed data, then it should also do this directly in memory. Only when the data is deemed 'complete' (for lack of a better word, meaning we needn't access/change the data anymore, at least anytime soon), it is written back to the file.
Of course, sometimes you have to write back stuff that is not 'completed' due to insufficient memory, BUT, your test does not allow the computer to run out of memory, as the file sizes were too small. I made sure to perform my random access test on a file larger than available RAM. Better... but not really good enough.
Maybe I'll try and include reading/changing/writing data, like some large programs may do, on a file both smaller and larger than available RAM. I think THIS is the way most real-world applications work - taking care to not re-read the same unchaged data... hmmm, do you think professional programmers get lazy, and instead of writing their own memory manager, that they just ask for the data directly from the file again, assuming Windows will help them enough? Do you think people change data in the file by reading/changing/writing, and then reading again when the data is needed again? I suppose this is possible... but very, very ugly...
I have re-done the same 3 tests above with the additional information. The %-ages are how fast the C runtime library is compared to the Win32 API. If it is < 100%, then C runtime is slower. If it is > 100%, then C runtime is faster.Quote:
Originally posted by _Elixia_
Nice work Jason! I know it can be done easily enough, but could you include %-age speed increase on each line, which is the result of using Win32 API over C-api?
The above times are pretty erratic. The 650 MB files are certainly using up as much memory as possible on my 512 MB system, and it appears the prior tests effect future tests. Should they? I have no idea... There is no data being written back to disk, so I would think this memory used for cache would be available for use on the next file in an insignificantly small amount of time.Code:SEQUENTIAL READ - 650 MB FILES INTO 1 MB BUFFER, 512 MB of RAM.
File access speed test - C runtime vs Win32 API - By: Jason Doucette
-----------------------------------------------------------------------------
type: C C C Win32 Win32 Win32 C spd C spd C spd
test: rb rbS rbR 0 SEQ RAND % of W % of W % of W
-----------------------------------------------------------------------------
# 1: 38583ms 29376ms 18299ms 29578ms 39269ms 16608ms 76% 133% 90%
# 2: 30448ms 18459ms 17768ms 62373ms 29583ms 16590ms 204% 160% 93%
# 3: 34691ms 29310ms 31884ms 33641ms 29441ms 15804ms 96% 100% 49%
# 4: 49692ms 42064ms 16355ms 28803ms 18037ms 36523ms 57% 42% 223%
# 5: 39686ms 29085ms 16147ms 46058ms 31446ms 15406ms 116% 108% 95%
# 6: 40074ms 28243ms 23231ms 35188ms 27918ms 15679ms 87% 98% 67%
# 7: 39540ms 24375ms 16226ms 38414ms 27980ms 15534ms 97% 114% 95%
# 8: 55819ms 29943ms 16088ms 34801ms 35100ms 16755ms 62% 117% 104%
# 9: 36575ms 28526ms 16047ms 49908ms 29157ms 16306ms 136% 102% 101%
#10: 34368ms 47799ms 16438ms 38339ms 27832ms 15498ms 111% 58% 94%
#11: 49350ms 19733ms 20685ms 34123ms 28871ms 35641ms 69% 146% 172%
#12: 34898ms 28836ms 16196ms 41028ms 21539ms 15863ms 117% 74% 97%
#13: 39051ms 29179ms 17150ms 55804ms 28790ms 15879ms 142% 98% 92%
#14: 38805ms 32995ms 17485ms 29575ms 28237ms 15763ms 76% 85% 90%
#15: 58967ms 17833ms 16267ms 37530ms 28987ms 15751ms 63% 162% 96%
#16: 58282ms 28926ms 16138ms 38386ms 29024ms 16112ms 65% 100% 99%
#17: 34709ms 28559ms 17299ms 50745ms 28190ms 16698ms 146% 98% 96%
#18: 33093ms 48236ms 18468ms 37536ms 28303ms 15559ms 113% 58% 84%
#19: 56813ms 17468ms 19634ms 31420ms 27828ms 34452ms 55% 159% 175%
#20: 34072ms 32461ms 17430ms 36229ms 26032ms 15845ms 106% 80% 90%
#21: 33015ms 28758ms 16505ms 65473ms 30023ms 16073ms 198% 104% 97%
#22: 35532ms 40782ms 16417ms 38223ms 28385ms 15736ms 107% 69% 95%
#23: 58790ms 20708ms 16484ms 35724ms 28163ms 15589ms 60% 136% 94%
#24: 50172ms 29342ms 17296ms 36213ms 36416ms 15823ms 72% 124% 91%
#25: 38030ms 29128ms 15938ms 48190ms 28296ms 16184ms 126% 97% 101%
#26: 34417ms 42479ms 16651ms 39396ms 28207ms 16306ms 114% 66% 97%
#27: 58497ms 30125ms 16363ms 33000ms 16539ms 35355ms 56% 54% 216%
#28: 37700ms 29349ms 16222ms 43848ms 21196ms 15645ms 116% 72% 96%
#29: 37676ms 19752ms 16026ms 47847ms 29190ms 15839ms 126% 147% 98%
#30: 32341ms 48445ms 16709ms 32402ms 19912ms 15987ms 100% 41% 95%
#31: 46864ms 29253ms 17534ms 34204ms 27690ms 15573ms 72% 94% 88%
#32: 56116ms 28876ms 16154ms 32780ms 34765ms 17129ms 58% 120% 106%
-----------------------------------------------------------------------------
avg: 42395ms 30262ms 17610ms 39899ms 28135ms 18422ms 94% 92% 104%
Since all 6 files can be cached into memory on my 512 MB system, the only results that matter are those from the first test. Do prior tests effect future ones? I would assume no, as they access different files, and I have enough memory that the caching of one should not need any memory from another. Also, the settings for sequential read is not even as good as the settings for random access... This really makes no sense. Btw, I booted the system before every test, to ensure that no caching was done on the files for the first run. The Win32 API fails miserably here... why?Code:SEQUENTIAL READ - 65 MB FILES INTO 1 MB BUFFER, 512 MB of RAM.
File access speed test - C runtime vs Win32 API - By: Jason Doucette
-----------------------------------------------------------------------------
type: C C C Win32 Win32 Win32 C spd C spd C spd
test: rb rbS rbR 0 SEQ RAND % of W % of W % of W
-----------------------------------------------------------------------------
# 1: 3574ms 1635ms 1649ms 3666ms 2977ms 1777ms 102% 182% 107%
# 2: 289ms 3198ms 265ms 275ms 1820ms 261ms 95% 56% 98%
# 3: 293ms 2910ms 265ms 281ms 2842ms 263ms 95% 97% 99%
# 4: 295ms 3576ms 273ms 282ms 3964ms 265ms 95% 110% 97%
# 5: 296ms 3787ms 262ms 273ms 2809ms 261ms 92% 74% 99%
# 6: 299ms 1614ms 263ms 282ms 2722ms 261ms 94% 168% 99%
# 7: 290ms 3189ms 264ms 284ms 2931ms 261ms 97% 91% 98%
# 8: 292ms 1629ms 263ms 276ms 2910ms 262ms 94% 178% 99%
# 9: 293ms 1624ms 264ms 277ms 2697ms 263ms 94% 166% 99%
#10: 296ms 1618ms 263ms 278ms 2674ms 265ms 93% 165% 100%
#11: 302ms 1696ms 266ms 278ms 2619ms 266ms 92% 154% 100%
#12: 307ms 1633ms 263ms 278ms 2646ms 261ms 90% 162% 99%
#13: 304ms 3682ms 264ms 277ms 2797ms 265ms 91% 75% 100%
#14: 295ms 2850ms 263ms 278ms 2846ms 263ms 94% 99% 100%
#15: 295ms 3203ms 266ms 278ms 1913ms 261ms 94% 59% 98%
#16: 295ms 2866ms 265ms 276ms 1921ms 261ms 93% 67% 98%
#17: 292ms 1801ms 267ms 280ms 1945ms 262ms 95% 107% 98%
#18: 291ms 1956ms 266ms 283ms 1930ms 264ms 97% 98% 99%
#19: 295ms 1850ms 265ms 283ms 1637ms 262ms 95% 88% 98%
#20: 295ms 1840ms 264ms 275ms 1628ms 262ms 93% 88% 99%
#21: 295ms 1878ms 264ms 278ms 1646ms 262ms 94% 87% 99%
#22: 295ms 2914ms 264ms 280ms 2790ms 261ms 94% 95% 98%
#23: 299ms 2826ms 265ms 276ms 2752ms 264ms 92% 97% 99%
#24: 301ms 2781ms 263ms 278ms 2731ms 262ms 92% 98% 99%
#25: 293ms 1819ms 266ms 281ms 1657ms 261ms 95% 91% 98%
#26: 304ms 1793ms 264ms 275ms 1612ms 262ms 90% 89% 99%
#27: 295ms 1738ms 265ms 279ms 1564ms 264ms 94% 89% 99%
#28: 303ms 2819ms 266ms 279ms 2732ms 263ms 92% 96% 98%
#29: 294ms 2860ms 266ms 285ms 1556ms 262ms 96% 54% 98%
#30: 299ms 2835ms 266ms 278ms 2742ms 263ms 92% 96% 98%
#31: 300ms 1659ms 263ms 284ms 1565ms 262ms 94% 94% 99%
#32: 297ms 1700ms 265ms 278ms 1567ms 263ms 93% 92% 99%
-----------------------------------------------------------------------------
avg: 398ms 2368ms 308ms 384ms 2348ms 309ms 96% 99% 100%
This random access test is reading the same, unchanged data, unlike a real world situation. I will try and find some time to modify this test to allow changing the data, and writing it back to memory, using a simple memory manager, much like a real world application would. I think this test, when finished, will show the most accurate results of emulating a real world situation. Any thoughts?Code:RANDOM ACCESS READ - 65 MB FILES INTO 1 MB BUFFER, 512 MB of RAM.
512 1-MB reads (from random location each time) per test
File access speed test - C runtime vs Win32 API - By: Jason Doucette
-----------------------------------------------------------------------------
type: C C C Win32 Win32 Win32 C spd C spd C spd
test: rb rbS rbR 0 SEQ RAND % of W % of W % of W
-----------------------------------------------------------------------------
# 1: 7647ms 4432ms 4215ms 4303ms 13581ms 4613ms 56% 306% 109%
# 2: 2369ms 15441ms 2045ms 2303ms 12262ms 1946ms 97% 79% 95%
# 3: 2385ms 10274ms 2035ms 2308ms 14884ms 1963ms 96% 144% 96%
# 4: 2385ms 11208ms 2060ms 2304ms 10151ms 1955ms 96% 90% 94%
# 5: 2376ms 9315ms 2047ms 2310ms 9579ms 1966ms 97% 102% 96%
# 6: 2379ms 10035ms 2043ms 2322ms 9921ms 1950ms 97% 98% 95%
# 7: 2376ms 9632ms 2039ms 2316ms 10328ms 1979ms 97% 107% 97%
# 8: 2478ms 11084ms 2048ms 2327ms 9489ms 1958ms 93% 85% 95%
# 9: 2382ms 9955ms 2096ms 2333ms 10075ms 1954ms 97% 101% 93%
#10: 2371ms 10073ms 2014ms 2307ms 9388ms 1954ms 97% 93% 97%
#11: 2384ms 11186ms 2053ms 2317ms 8955ms 1947ms 97% 80% 94%
#12: 2391ms 9666ms 2061ms 2307ms 10546ms 1961ms 96% 109% 95%
#13: 2375ms 10479ms 2060ms 2315ms 9506ms 1957ms 97% 90% 95%
#14: 2374ms 9187ms 2042ms 2320ms 11029ms 1977ms 97% 120% 96%
#15: 2386ms 8968ms 2042ms 2315ms 10454ms 1944ms 97% 116% 95%
#16: 2390ms 8891ms 2050ms 2313ms 10444ms 1973ms 96% 117% 96%
#17: 2389ms 9498ms 2043ms 2323ms 9858ms 1949ms 97% 103% 95%
#18: 2396ms 10038ms 2051ms 2314ms 9528ms 1959ms 96% 94% 95%
#19: 2379ms 9501ms 2046ms 2323ms 9004ms 1949ms 97% 94% 95%
#20: 2392ms 9305ms 2026ms 2333ms 10077ms 1961ms 97% 108% 96%
#21: 2471ms 12002ms 2039ms 2311ms 9947ms 1968ms 93% 82% 96%
#22: 2392ms 10027ms 2039ms 2318ms 9046ms 1957ms 96% 90% 95%
#23: 2384ms 10629ms 2035ms 2319ms 9454ms 1951ms 97% 88% 95%
#24: 2397ms 10559ms 2034ms 2323ms 9919ms 1960ms 96% 93% 96%
#25: 2391ms 9462ms 2088ms 2383ms 11285ms 1957ms 99% 119% 93%
#26: 2394ms 9542ms 2067ms 2325ms 9866ms 1963ms 97% 103% 94%
#27: 2387ms 9707ms 2052ms 2320ms 10256ms 1957ms 97% 105% 95%
#28: 2405ms 9032ms 2050ms 2321ms 9933ms 1959ms 96% 109% 95%
#29: 2394ms 10374ms 2070ms 2312ms 8873ms 1964ms 96% 85% 94%
#30: 2406ms 10485ms 2053ms 2327ms 9373ms 1984ms 96% 89% 96%
#31: 2430ms 10078ms 2042ms 2325ms 9171ms 1972ms 95% 91% 96%
#32: 2390ms 8826ms 2031ms 2323ms 10186ms 1952ms 97% 115% 96%
-----------------------------------------------------------------------------
avg: 2557ms 9965ms 2116ms 2381ms 10199ms 2042ms 93% 102% 96%
I have created another test that emulates a memory manager. The program allocates 50% of available unused RAM for its memory cache. It reads/writes sections from/to the file, but never re-reads in a section from the file that is already cached (the win32 API has proven to be much better at re-reading unchanged data from a file multiple times, but you should never have to do this, so it is meaningless). It only writes out a section when it needs space for a read. It runs on the basis of last access - the last accessed section in cache is the one written out, before reading in a new section that has not been cached, yet. The program choses random sections, but does so in a way that certain sections are accessed more often, just as would happen in a real world application. The program does not modify the data to ensure that this would not interfere with the timing. I use the high resolution performance counter, which is more accurate than 1 ms. Times are rounded off to 1 ms.Quote:
Originally posted by JasonD
I will try and find some time to modify this test to allow changing the data, and writing it back to memory, using a simple memory manager, much like a real world application would. I think this test, when finished, will show the most accurate results of emulating a real world situation.
The results are below:
Please note that, again, I test all three possibilities of access for the C runtime library, and for the Win32 API. The only one that actually matters is the random access (i.e. the 3rd one, the ones that are bolded), because this is what we are doing. You'll see that the results for C runtime and Win32 API are the same - within 1% of each other (99% means the C runtime went 99% of the speed of the win32 API).Code:File Access Speed Test - C Runtime vs. Win32 API - By: Jason Doucette
--> Random Access Read/Write test.
Total size of physical memory = 536334336 bytes = 511.5 MB.
Size of physical memory available = 359559168 bytes = 342.9 MB.
File sizes = 253822000 bytes = 242.1 MB.
Buffer size = 1048576 bytes = 1 MB.
Number of full buffer-sized sections in file = 242.
Percentage of available memory used for memory cache = 50%
Number of buffers in memory cache = 171
Size of memory cache = 179306496 bytes = 171 MB.
Number of random read/write sections to be performed per test = 8192
-----------------------------------------------------------------------------
type: C C C Win32 Win32 Win32 C spd C spd C spd
test: rb rbS rbR 0 SEQ RAND % of W % of W % of W
-----------------------------------------------------------------------------
# 1: 57284ms 64514ms 26739ms 25414ms 72988ms 17759ms 44% 113% 66%
# 2: 18625ms 63979ms 15700ms 22359ms 61082ms 16932ms 120% 95% 107%
# 3: 17364ms 65151ms 15914ms 16696ms 66792ms 16236ms 96% 102% 102%
# 4: 17294ms 63841ms 16700ms 16790ms 60186ms 15924ms 97% 94% 95%
# 5: 19296ms 62884ms 15782ms 16540ms 63671ms 16016ms 85% 101% 101%
# 6: 16932ms 64949ms 16284ms 16280ms 60153ms 16424ms 96% 92% 100%
# 7: 19418ms 61968ms 15725ms 16646ms 63889ms 16013ms 85% 103% 101%
# 8: 17443ms 65307ms 16108ms 16172ms 59846ms 18576ms 92% 91% 115%
# 9: 17500ms 62046ms 15726ms 16329ms 63671ms 15986ms 93% 102% 101%
#10: 17589ms 65497ms 15814ms 16625ms 62869ms 16458ms 94% 95% 104%
#11: 17767ms 62268ms 15974ms 21721ms 60498ms 15919ms 122% 97% 99%
#12: 17565ms 65412ms 15870ms 16301ms 63089ms 16274ms 92% 96% 102%
#13: 17205ms 61683ms 18153ms 16837ms 60411ms 15883ms 97% 97% 87%
#14: 17232ms 65461ms 15817ms 16442ms 63350ms 16103ms 95% 96% 101%
#15: 17203ms 64999ms 16359ms 16607ms 60292ms 15981ms 96% 92% 97%
#16: 21799ms 62399ms 15706ms 16363ms 63456ms 16046ms 75% 101% 102%
#17: 17402ms 65582ms 15929ms 16545ms 59884ms 18170ms 95% 91% 114%
#18: 17892ms 62801ms 15697ms 16429ms 64675ms 16102ms 91% 102% 102%
#19: 17660ms 70109ms 15803ms 16467ms 62738ms 16475ms 93% 89% 104%
#20: 17412ms 61752ms 16686ms 17210ms 63147ms 15996ms 98% 102% 95%
#21: 17600ms 65842ms 15784ms 16650ms 63457ms 16218ms 94% 96% 102%
#22: 17212ms 66307ms 16386ms 17067ms 60263ms 15913ms 99% 90% 97%
#23: 19320ms 63085ms 15837ms 16534ms 64138ms 16104ms 85% 101% 101%
#24: 17367ms 64699ms 16144ms 16844ms 60044ms 15979ms 96% 92% 98%
#25: 20242ms 64575ms 15780ms 16788ms 63257ms 15929ms 82% 97% 100%
#26: 17468ms 65774ms 15962ms 16617ms 62722ms 17926ms 95% 95% 112%
#27: 17607ms 62195ms 15693ms 18479ms 61087ms 16040ms 104% 98% 102%
#28: 17115ms 67016ms 15881ms 16363ms 64190ms 16501ms 95% 95% 103%
#29: 17818ms 61585ms 17046ms 17191ms 62555ms 16328ms 96% 101% 95%
#30: 18077ms 65391ms 15782ms 16842ms 63468ms 16240ms 93% 97% 102%
#31: 17491ms 64148ms 17964ms 16605ms 60239ms 15978ms 94% 93% 88%
#32: 20153ms 62823ms 15703ms 16736ms 63519ms 16312ms 83% 101% 103%
-----------------------------------------------------------------------------
avg: 19229ms 64251ms 16451ms 17296ms 62675ms 16398ms 89% 97% 99%
C runtime may actually be a bit faster, if you ignore the first rep (I think the first rep may show slower times than normal since I locked my workstation when the test started), as there are mostly high 15Ks for C runtime, and mostly low 16Ks for Win32 API, which are the best times for both sides. You can see by the percentage comparison that the C runtime is quicker for the majority of the tests than the Win32 API.
Conclusion: It looks to me that there is no advantage to using the Win32 API over the C Runtime library. I would personally still use wrappers, anyway, so what you use under those wrappers is completely up to you.
Thanks for all the work you have put in Jason. I reckon this post should be saved as it's a good reference for people deciding on there implementation.