Why is ifstream :: read much faster than using iterators?

Question

As is, there are many approaches to reading a file in a line. Two common methods use ifstream :: read to read the line directly and use steambuf_iterators along with std :: copy_n:

Using ifstream :: read:

std::ifstream in {"./filename.txt"}; std::string contents; in.seekg(0, in.end); contents.resize(in.tellg()); in.seekg(0, in.beg); in.read(&contents[0], contents.size()); 

Using std :: copy_n:

 std::ifstream in {"./filename.txt"}; std::string contents; in.seekg(0, in.end); contents.resize(in.tellg()); in.seekg(0, in.beg); std::copy_n(std::streambuf_iterator<char>(in), contents.size(), contents.begin(); 

Many tests show that the first approach is much faster than the second (on my machine using g ++ - 4.9 it is about 10 times faster with the -O2 and -O3 flags), and I was wondering what could be the reason for this difference in performance.

Answer 1

read is a single iostream setup (part of every iostream operation) and one OS call directly read into the buffer that you provided.

The iterator works by repeatedly extracting one char with operator>> . Due to the size of the buffer, this may mean more OS calls, but, more importantly, it also means reconfiguring and disabling the iostream clock, which can mean locking the mutex and usually means a bunch of other things. In addition, operator>> is a formatted operation, while read unformatted, which is an additional overlay for each operation.

Edit: Tired eyes saw istream_iterator instead of istreambuf_iterator. Of course, istreambuf_iterator does not do formatted input. It calls sbumpc or something similar on streambuf. There are still a lot of calls and the use of a buffer, which is probably smaller than the entire file.