Are C++ << and >> operators slow? What alternatives are there to these operators?

Question

I'm doing a project for college and I'm using C++. I used std::cin and std::cout with the << and >> operators to read input and to display output. My professor has published an announcement saying that >> and << are not recommended because they are slow.

We only have to read integers and the input is always correct (we don't need to verify it, we know the format it is in and just need to read it). What alternatives should we use then, if << and >> are not recommended?

Smells of premature optimization, if professor's message is accurate and complete here. — Drew Dormann, Mar 18 '15 at 21:00
Maybe he wants you to use the C style IO functions like `printf`, `scanf` and friends. — David G, Mar 18 '15 at 21:01
@0x499602D2: Maybe, but I don't know of any reason to assume they're faster than `std::cout << ...` and `std::cin >> ...`. Note that `printf` has to parse the format string. — Keith Thompson, Mar 18 '15 at 21:10
Has the professor profiled the operators to back up his claim that they are slow? And slow compared to what exactly? What is *his* alternative? — Remy Lebeau, Mar 18 '15 at 21:10
There is some prior discussion on the issue of efficiency: http://stackoverflow.com/questions/605839/c-and-c-file-i-o As a personal note, if you are taking an introductory programming class, there is no reason you should be worried about this kind of efficiency. — mattm, Mar 18 '15 at 21:10
@RemyLebeau: The normal complaints revolve around the fact that `iostreams` use a virtual function call for each _byte_ written, even for unformatted reads/writes, and the locks involved when they're tied to the C streams, which is the default state. — Mooing Duck, Mar 18 '15 at 21:14
As far as I know, the standard advice is to avoid mixing printf and cout in the same program. Only then will you pay for the synch between type-safe C++ iostreams and legacy C I/O. — Erik Alapää, Mar 18 '15 at 21:21
@0x499602D2, I find that weird but if there are no other alternative, I guess I'll have to do that. — Hel, Mar 18 '15 at 21:41
@RemyLebeau, that's the thing. He didn't say anything. He gave examples for Java, but for C++ he just said that. — Hel, Mar 18 '15 at 21:43
@mattm, I'm taking an algorithms class, so it's all about efficiency. That's why I'm concerned. — Hel, Mar 18 '15 at 21:43
@Helena: So your professor is claiming that Java is faster than C++, without proof? Wow. Good luck in your class. — Remy Lebeau, Mar 18 '15 at 21:51
@RemyLebeau, no. This project can be done in one of three languages: C, C++ or Java. I only chose C++ over C because it has a lot of data structures implemented that would be very useful. There are some people that tried to do in Java but they can't pass all tests, so he published an announcement saying that, in C++, << and >> operators were not recommended because they were slower and then gave a few examples for those using Java. Never did he say that Java is faster than C++, he just told us what we should use in Java to I/O. — Hel, Mar 18 '15 at 21:56
The efficiency of you program is based on the efficiency of the algorithm, not the implementation of things like I/O routines. Concepts such as "linear search" versus "binary search" should be your concern. Most of your code will not be large enough to warrant concern over the speed of I/O. — Thomas Matthews, Mar 18 '15 at 22:22
@ThomasMatthews, the program is done and the algorithms were all chosen carefully given the problem. My concern with I/O is due to my professor's recommendation not to use << and >>, no other reason. — Hel, Mar 19 '15 at 00:36

score 3 · Answer 1 · answered Mar 18 '15 at 21:11

3

For cout you can use put or write

// single character
char character;
cout.put(character);

// c string
char * buffer = new char[size];
cout.write(buffer, size);

For cin you could use get, read, or getline

// Single character
char ch;
std::cin.get(ch); 

// c string
char * buffer = new char[size];
std::cin.read(buffer, size);
std::cin.get(buffer, size);
std::cin.getline(buffer, size);

answered Mar 18 '15 at 21:11

Craig K

86
1
5

I don't think these are significantly faster than the `<<` versions, and you don't provide a way to handle integers. – Mooing Duck Mar 18 '15 at 21:15
Much of the loss of efficiency is due to the translation from a textual representation to the internal representation. – Thomas Matthews Mar 18 '15 at 22:31
Thanks for you answer. I ended up using scanf and printf instead. – Hel Mar 19 '15 at 00:37

score 0 · Accepted Answer · answered Mar 18 '15 at 22:30

Worrying about the speed of the stream extraction operators (<< and >>) in C++ is something to do when you have lots of data to process (over 1E06 items). For smaller sets of data, the execution time is negligible to other factors with the computer and your program.

Before you worry about the speed of formatted I/O, get your program working correctly. Review your algorithms for efficiency. Review your implementation of the algorithms for efficiency. Review the data for efficiency.

The slowness of the stream extraction operators is first translating from textual representation to internal representation, then the implementation. Heck, if you are typing in the data, forget about any optimizations. To speed up your file reading, organize the data for easy extraction and translation.

If you are still panicking about efficiency, use binary file representation. The data in the file should be formatted so that it can be loaded directly into memory without any translations. Also, the data should be loaded in large chunks.

From the Hitchhiker's Guide to the Galaxy, DON'T PANIC.

I ended up using scanf and printf instead (which made it a little bit faster). Thanks for the binary file representation idea though, it is worth looking into. — Hel, Mar 19 '15 at 00:38

Are C++ << and >> operators slow? What alternatives are there to these operators?

2 Answers2