Is there a faster way to load a file in C++ using the command line?

Question

I want to load one million random integers from a .txt into a vector using the command line:

program.exe < million-integers.txt

My code below works, but takes several seconds to run. Is there something I can do to make it faster? I've found some solutions on SO, but they all seem to relying on hard-coding the filepath. I want to be able to pass a filename through the command line.

vector<int> data;
int input;

while (cin >> input)
{
    data.push_back(input);
}
cout << "Data loaded." << endl;

(C++ noob using Visual Studio on Win 8.1)

Edit: In this case, I know that some improvement can be made since I have someone else's .exe that can do it in under a second.

Edit: All integers are on the same line.

Answer 1

Run time: 4.08s. What? That's slow!

Why is this happening?

I did profiling. I'm using a very different system: OS X 10.8, with Clang, but my program is also slow, and I suspect it is for the same reason. Here are two lines from the profiling results (apologies for formatting):

Running Time    Self        Symbol Name
3389.0ms   79.3%    76.0             std::__1::num_get<char, std::__1::istreambuf_iterator<char, std::__1::char_traits<char> > >::do_get(std::__1::istreambuf_iterator<char, std::__1::char_traits<char> >, std::__1::istreambuf_iterator<char, std::__1::char_traits<char> >, std::__1::ios_base&, unsigned int&, long&) const
824.0ms   19.2% 8.0          std::__1::basic_istream<char, std::__1::char_traits<char> >::sentry::sentry(std::__1::basic_istream<char, std::__1::char_traits<char> >&, bool)

As you can see, these two functions account for almost 98.5% of the execution time. Wow! When I drill down, what are these library functions calling that takes so much time?

• flockfile()
• funlockfile()
• pthread_mutex_unlock()

So, on my system, the implementation for std::cin works with C's <stdio.h> functions so they can both be used in the same program, and these functions make sure to synchronize with other threads. This is inefficient.

1. There is no code using <stdio.h>, so there is no need synchronize with it.

2. There is only one thread using stdin, so locking is excessive, especially if you lock once per character read. That's super excessive. Locks and system calls are pretty fast... but if you do something like 10 million locks and system calls? No longer fast.

Note: Yes, I am running OS X, and the actual functions will be different on Windows. Instead of flockfile() and pthread_mutex_unlock() you will see whatever the Windows version is.

Solution #1

Stop using redirection. If you use ifstream, then it is assumed that you will take care of locking yourself. On my system, this give a runtime of 0.42 seconds—close to a factor of 10.

Solution #2

Read everything into a string, and then parse the string. This allows you to continue using redirection to read the file.

Solution #3

Disable locking on std::cin. Sorry folks, I don't know how to do that. It might be possible.

Performance limits

I suspect the ifstream version is nowhere near the performance limit of your computer. If performance were critical, I suspect you can get the warm-cache runtime close to 2 or 3 ms, when your program is only limited by memory bandwidth.

Answer 2

There are two things you might try.

1. use std::vector<T>::reserve to size your vector up front
2. use std::iostream::read to read the data in 4K (or bigger) blocks and parse the data yourself.

iostreams are supposed to be buffered and vectors are suppose to have a good resize strategy but sometimes these things do not work as well as expected.

Answer 3

Use regular ifstream instead of cin. Pass the name of the file on command line (vargs) and open it, instead of using cin.

int main(int argc, char *argv[]){
  vector<int> data;
  int input;
  ifstream in;
  in.open(argv[1]);
 
  while (in >> input)
  {
        data.push_back(input);
  }
  cout << "Data loaded." << endl;
}

@DietrichEpp shed more light on why my solution was 10 times faster. When you use cin, it tries to be thread safe and adds extra synchronization overhead making it run much slower.

---

I have verified that my solution works and it runs 10 times faster. I'm using MacBook Pro (2012 I think) with a flash drive

cpp $ruby gen_data.rb > data.txt 
cpp $c++ -O3 test1.cpp 
cpp $time ./a.out < data.txt 
Data loaded.

real    0m3.048s
user    0m3.023s
sys 0m0.011s
cpp $c++ -O3 test2.cpp 
cpp $time ./a.out data.txt 
data.txtData loaded.

real    0m0.351s
user    0m0.334s
sys 0m0.010s

Answer 4

Another option you may want to look into is ios_base::sync_with_stdio, which defaults to true. This options forces std::cin to read each block as a separate chunk in order to allow you to intertwine C operations with C++. This slows down reading a lot. A more detailed analysis can be found in this answer.

Answer 5

Yes, and No. Yes, there is a faster way to retrieve the data once the OS gives it to you. No, your program is at the mercy of the OS and the OS will send data from the file to your program as the OS chooses (There may be other tasks that can interrupt your program from receiving data continuously).

Read large amounts into memory
Memory is always faster to search than a device, such as a thumb drive or hard drive.

One read request for a large amount of data is usually much faster than many read requests for a small amount of data.

Combining these facts states that you should allocate (reserve) a large amount of memory and read into the memory. This may need to be repeated depending on the amount of memory you can reserve and the size of the file.

Example:

  const unsigned int BUFFER_SIZE = 1024 * 1024;
  char buffer[BUFFER_SIZE];
  cin.read(buffer, BUFFER_SIZE);

Use std::istringstream
You can create an std::istringstream that uses the buffer. Thus you can "read" your integers from the text buffer as you would from cin or a text file.

Overhead of file redirection
When you redirect the output of a file to the input of your program, the OS must open the file, read some data from the file, then pass it to your program. This overhead is the principle bottleneck of your program. If your program would open the file directly, you could avoid the overhead and make your program run faster.

Search the web for "C++ cin rdbuf setbuf" for information on redirecting cin to use a buffer of your choosing.