• ### Announcements

#### Archived

This topic is now archived and is closed to further replies.

# good c file i/o articles

## Recommended Posts

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

##### Share on other sites
_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. )

##### Share on other sites
But the C++ stream classes are slower than the C standard functions .

"Finger to spiritual emptiness underlying everything." -- How a C manual referred to a "pointer to void." --Things People Said

http://www.gdarchive.net/druidgames/

##### Share on other sites
(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.

##### Share on other sites
====================================C_IOEnter a number of bytes to read.10000000Time to open : 5943 usTime to read 10000000 byte(s): 110142 usTime to read 10000000 byte(s): 57292 usTime to close : 88 usC_IOEnter a number of bytes to read.10000000Time to open : 5819 usTime to read 10000000 byte(s): 110308 usTime to read 10000000 byte(s): 57305 usTime to close : 84 us=====================================C++_stream_IOEnter a number of bytes to read.10000000Time to open : 6080 usTime to read 10000000 byte(s): 136373 usTime to read 10000000 byte(s): 120010 usTime to close : 147 usC++_stream_IOEnter a number of bytes to read.10000000Time to open : 5763 usTime to read 10000000 byte(s): 135635 usTime to read 10000000 byte(s): 120512 usTime to close : 91 us===========================================

This is the output of the program that is used to test it. I have the zip file with all of the C/C++ files used to test this, it looks pretty well done, if you''d like to take a look.

"Finger to spiritual emptiness underlying everything." -- How a C manual referred to a "pointer to void." --Things People Said

http://www.gdarchive.net/druidgames/

##### Share on other sites
Done . If you find any inherant flaws in it, please point them out, as I''m always out for the truth, not just for bias . Now I need to find out what''s wrong with my sig. banner...

"Finger to spiritual emptiness underlying everything." -- How a C manual referred to a "pointer to void." --Things People Said

http://www.gdarchive.net/druidgames/

##### Share on other sites
*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.

##### Share on other sites
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.

##### Share on other sites
Actually, most of my files in my games are at least 100,000 bytes , so common cases will differ. Well, that''s a thorough analysis at least, it shouldn''t change all too much depending on compiler or CPU.

"Finger to spiritual emptiness underlying everything." -- How a C manual referred to a "pointer to void." --Things People Said

http://www.gdarchive.net/druidgames/

##### Share on other sites
Yes, obviously, most files will be greater than 100,000 bytes. However, people rarely read them all in one statement. That's why we have cached and buffered file reading, so we can read in 4-byte ints which describe sizes and IDs and all sorts of other small things, without having to buffer it ourselves by loading the whole file into memory and then parsing through it to find what we want.

Of course, there are .wav files and other media files that are typically very large, but I let the OS functions load those.

Edited by - null_pointer on March 23, 2001 4:29:00 PM

• ## Partner Spotlight

• ### Forum Statistics

• Total Topics
627682
• Total Posts
2978615

• 13
• 12
• 10
• 12
• 22