Hi! I reacently started with som e filehandling stuff in c and found this very strange. I know about the fgetc and fscanf but then i saw in a piece of code _lread...wow this seems cool i thought and now i wonder if anyone knows where i can find good articles bout this?? man i wish i was back with Ada filehandling --spencer

_lread, _lwrite, etc. are deprecated Win16 functions dating back to the days of Windows 3.1. You should use ReadFile, WriteFile, etc. instead, as these are Win32 functions.

fread, fwrite, etc. are standard C functions, so you will find implementations of them on Linux, Mac, etc. The other functions I''ve been talking about are specific to Windows. If you don''t need the Windows file I/O functions specifically, then it''s generally best to use the more portable C functions.

(Of course, the C++ stream classes are better designed, but that''s beside the point. )

(For the moment I''ll assume that the test criteria were suitable for an objective comparison, and I''ll assume that the tester knew how to use the C++ streams properly, and I''ll assume that the test results did indeed prove the C++ streams slower by a relatively significant margin. )

That would be because the C++ streams check the return values like C programmers should be doing.

Send it.

*sigh* I dislike Hungarian Notation. But the timer is interesting.

Thanks for the code! After running the tests many times, alternating between C_IO and C++_stream_IO, the stream I/O beats the pants off C''s file I/O at values less than 10,000 bytes, which I must say is fairly large data size for my code. I usually write 4-byte quantities and somewhat larger structs, but I don''t think I''ve ever written anything as large as 10 MB. I assume you were trying to eliminate the file cache and possibly other external factors from interfering with the test results?

The test takes a filename, a method, and the number of bytes to read. It then ups its priority to time-critical to avoid interruptions which could conflict with the test results. Then it makes two reads, so it actually reads twice as many bytes as you''ve input.

I tested by picking a suitably large file and depositing it in the project directory, and then adjusting the project settings to eliminate the build errors. This included added the preprocessor definition "WINDOWS" and including the "winmm.lib" which is necessary for the timer. Other than that, no changes were made to the default project settings to skew the results. I then built the release version, fired it up, and started testing. I tried running the C++_stream_IO first, then alternating between C_IO and C++_stream_IO. The first read is always slower, no matter what method is used, probably because of the disk cache affecting sequential reads. I discarded the first test run when switching between file sizes, since the file cache interferes with the results.

Average results:

• When reading < 1,000 bytes, C++ is about 1000% faster than C on the first read, and only insignificantly faster than C on the second read(50/1 vs. 550/~1us (unmeasurable consistently, however always >= C++ second run)).


• When reading 1,000 bytes, the lead narrows with C++ being about 600% faster on the first read, and 500% slower on the second read (70/32 vs. 515/6).


• When reading 5,000 bytes, C++ is about 350% faster on the first read, and 100% faster on the second read (200/170 vs. 900/350).
  
• When reading 10,000 bytes, C++ is a little less than 100% faster on the first read, and about 66% faster on the second read. (430/330 vs. 830/515).


• When reading 100,000 bytes, C is about 50% faster on the first read, and 125% faster on the second read (4800/3800 vs. 3200/1700).

On all tests, it is worth noting that while C++ takes slightly longer to open a file, it always closes a bit faster. However, I doubt this is very important. The dependency of the test results on the test data size would seem to indicate that the difference in performance is due to C++''s stream buffer.

(Since this is a comparison between C file I/O and C++ file I/O, we have to disqualify the other two tests, as they use non-standard functions.)

So, for simple game programming, I would advise you to use C++ because it''s faster in the most common cases.

Oh, before anyone has a fit, I was only joking about recommending C++ file I/O based solely upon these test results. I simply want to nuke the idea that C is always faster than C++ code.