Writing to file line by line vs writing whole text at once - c++

Question

I always told that file io processes are the slowest ones. However when I test the two processes below:
Scenario 1:
test.open("test.xml",fstream::out);
for(int i=0;i<1000;i++)
{
test<<"<p> attr1=\"test1\" attr2=\"test2\" attr3=\"test3\" attr4=\"test4\">test5</p>\n";
}
test.close();
Scenario 2:
test.open("test.xml",fstream::out);
stringstream fileDataStr;
for(int i=0;i<1000;i++)
{
fileDataStr<<"<p> attr1=\"test1\" attr2=\"test2\" attr3=\"test3\" attr4=\"test4\">test5</p>\n";
}
test<<fileDataStr;
test.close();
I expect the senario1 to be slower because it does 1000 file io but test result showed that it has the same speed with scenario2 (in terms of clock_t). Why this is so, is it related with OS optimization as in file read?
getline while reading a file vs reading whole file and then splitting based on newline character
Edited: With the advice of #irW
string fileDataStr;
changed to
stringstream fileDataStr;

Answer 1

Because of the way std::ofstream buffers output, you end up
doing exactly the same amount of IO in both cases. (Usually,
at any rate—an implementation could optimize things when
you output a very long string.) The only difference is that in
the second case, you've introduced an additional intermediate
buffer, which means a little more copying, and a few more
dynamic allocations. (How many dynamic allocations depends on
the implementation, but it shouldn't be too many.)

Answer 2

Each time you have fileDataStr+=you are making a new string and copying the previous one into it, strings are immutable! If you would use a stringstream it might be a more fair comparison.

Answer 3

There is no one answer to this, because the results can and will vary with the compiler and standard library you use. For example, I put your different attempts together into a single program with a little test/timing harness. Then, just for fun, I added a fourth attempt (test3 in the code below):
#include <iostream>
#include <vector>
#include <string>
#include <sstream>
#include <time.h>
#include <fstream>
#include <sstream>
#include <string.h>
static const int limit = 1000000;
void test1() {
std::ofstream test("test.xml");
for (int i = 0; i < limit; i++)
{
test << "<p> attr1=\"test1\" attr2=\"test2\" attr3=\"test3\" attr4=\"test4\">test5</p>\n";
}
test.close();
}
void test11() {
std::ofstream test("test.xml");
std::string fileDataStr;
for (int i = 0; i < limit; i++)
{
fileDataStr += "<p> attr1=\"test1\" attr2=\"test2\" attr3=\"test3\" attr4=\"test4\">test5</p>\n";
}
test << fileDataStr;
test.close();
}
void test2() {
std::ofstream test("test.xml");
std::stringstream fileDataStr;
for (int i = 0; i < limit; i++)
{
fileDataStr << "<p> attr1=\"test1\" attr2=\"test2\" attr3=\"test3\" attr4=\"test4\">test5</p>\n";
}
test << fileDataStr.str();
test.close();
}
void test3() {
std::ofstream test("test.xml");
std::vector<char> buffer;
char line [] = "<p> attr1=\"test1\" attr2=\"test2\" attr3=\"test3\" attr4=\"test4\">test5</p>\n";
size_t len = strlen(line);
buffer.reserve(limit * len + 1);
for (int i = 0; i < limit; i++)
std::copy(line, line + len, std::back_inserter(buffer));
test.write(&buffer[0], buffer.size());
test.close();
}
template <class T>
void timer(T f) {
clock_t start = clock();
f();
clock_t stop = clock();
std::cout << double(stop - start) / CLOCKS_PER_SEC << " seconds\n";
}
int main() {
timer(test1);
timer(test11);
timer(test2);
timer(test3);
}
Then I compiled it with VC++, and got the following results:
0.681 seconds
0.659 seconds
0.874 seconds
0.955 seconds
Then, I compiled with g++, and got these results:
1.267 seconds
0.725 seconds
0.795 seconds
0.649 seconds
The fourth version (the one I added) gives the worst performance with VC++, but the best performance with g++. The one that was next to fastest with VC++ is (by far) the slowest with g++.
You're asking why X is true. Unfortunately, X isn't consistently true at all.
We'd probably have to do pretty detailed analysis of the exact compiler and standard library you were using to give an answer that really meant much.