File I/O preferrence
Author
I''ve done some testing with both standard C file I/O (fopen, fwrite/fread,etc) and STL fstreams as far as speed differences and didn''t find either noticebly faster.
I''m comfortable using either, I was just curious as to which one you guys/gals prefer and why. Which (if either) is considered the de facto standard for games?
***This all pertains to binary read/write ops, I have settled on using fstreams for text file I/O mainly because of it''s type safety with the << & >> operators.***
win32 ReadFile/WriteFile when i''m just writing binary data. no need to have overhead of stdio/iostreams on top of those if i don''t need it.
stdio for formatted i/o, most often it''s fprintf/fscanf. writing formatted data with ostream is a pain (but boost has format library which is supposed to make this easier).
iostreams when i need to input data into strings of unknown length, but usually nothign beyond that. i''m very suspicious of iostreams because every time i use them for something more complex than a few lines of code i end up screwing myself 50 times over and going back to whatever i was using before.
last time i rewrote my strtok-based parser using stringstreams, which absolutely killed performance. i was using getline() to read lines from first-generation string stream, creating a second-generation stringstream on the resulting line for reading formatted data from there. four extra dynamic memory allocations for every character processed, three extra copies, 100,000+ total memory allocations on load time, load time increased around tenfold. result: a strtok-with-a-twist implementation based on what i had before.
as far as speed is concerned, disk i/o will usually be your bottleneck. however, on machines with large amounts of physical memory, data may potentially be cached, and for large files, i suspect it will be possible to see the difference between win32 and iostream implementations.
stdio for formatted i/o, most often it''s fprintf/fscanf. writing formatted data with ostream is a pain (but boost has format library which is supposed to make this easier).
iostreams when i need to input data into strings of unknown length, but usually nothign beyond that. i''m very suspicious of iostreams because every time i use them for something more complex than a few lines of code i end up screwing myself 50 times over and going back to whatever i was using before.
last time i rewrote my strtok-based parser using stringstreams, which absolutely killed performance. i was using getline() to read lines from first-generation string stream, creating a second-generation stringstream on the resulting line for reading formatted data from there. four extra dynamic memory allocations for every character processed, three extra copies, 100,000+ total memory allocations on load time, load time increased around tenfold. result: a strtok-with-a-twist implementation based on what i had before.
as far as speed is concerned, disk i/o will usually be your bottleneck. however, on machines with large amounts of physical memory, data may potentially be cached, and for large files, i suspect it will be possible to see the difference between win32 and iostream implementations.
It matters not at all.
If you use C++, you might as well use iostreams. If you use C, use stdio. If your code has other win32 stuff in it, you can use Windows API functions if you wish. Those are just general guidelines, though. Use what you feel comfortable with.
Speed relly should be of no concern. If you are reading from files in time critical sections, you might want to rethink your design.
If you use C++, you might as well use iostreams. If you use C, use stdio. If your code has other win32 stuff in it, you can use Windows API functions if you wish. Those are just general guidelines, though. Use what you feel comfortable with.
Speed relly should be of no concern. If you are reading from files in time critical sections, you might want to rethink your design.
quote:Original post by Anonymous Poster
Speed relly should be of no concern. If you are reading from files in time critical sections, you might want to rethink your design.
people with lots of ram appreciate fast level reloads. reloads, namely loading files from disk cache, is where i/o subsystem overhead demonstrates itself most clearly. iostreams are nice, but they make a lot of data copies, which may be unnecessary; see above.
If you''re just doing regular I/O stuff, it''s not really important. But if speed is of consern, use the Win32 libraries. Not because they''re inherently faster (they''re not, really, since the C/C++ versions, obviously, use the Win32 stuff internally) but because they have more features which allow you to do various things (like overlapped I/O, and you can control the buffering and so on) to help speed your I/O up.
If I had my way, I''d have all of you shot!
codeka.com - Just click it.quote:Original post by Dean Harding
they''re not, really, since the C/C++ versions, obviously, use the Win32 stuff internally
um, what? have you actually looked at the source code for iostreams and stdio/low-level i/o routines? while msvc7 iostreams appear to be mostly transparent wrappers for stdio, they nonetheless contain boatloads of init/cleanup/management code of their own. in multithreaded version of crt, stdio performs critical section locks for most/all file operations (in addition to the locks in iostreams for i.e. locale stuff). stdio also has internal buffering, besides what os already provides, which means that you get an extra copy of the file pulled through memory. try and count the number of function calls that are made while a read/write requests gets to ReadFile/WriteFile or the stdio file buffer, and then back to the caller. just because iostreams and stdio use file win32 internally, doesn''t mean they provide equivalent performance*, as you so ignorantly assume.
* again, i''m stressing reading from disk cache.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
