while working in c/c++,
1.cin/cout or 2.scanf/printf ,
which one of both , will have less execution or run time. OR both will have equal runtime.
my aim is to reduce the runtime of my code.
cin or printf?
To bet on relative timings of console IO functions is imho without any real use. This is completely unpredictable (depends on environment). Console output depends completely on the speed of the console and usually not on the speed of the printf/cout. Try using local file output instead of console output.
This is a very good point. Of course, with redirection any of
cin, cout, scanf, printf could be doing file I/O. –
Kitchener Performance Rule #1 - measure, then optimize
Before you try to figure out if cin/cout or scanf/printf will be faster, make sure you have measured and proved this is indeed the biggest performance issue with your application.
Since nobody has mentioned it yet, here comes a belated reply:
C++' IO streams are type-safe. When you want to print a double, the compiler finds out it's a double and inserts a call to the right overload of operator<<() at compile-time. With the C IO functions, OTOH, you have to specify the types manually, and thus can easily make errors that are only caught at run-time. (Just do std::printf("%d", 47.11) and you're deep in Undefined Behavior land.)
Oh yeah, that and: either of those two might easily keep up with the console. So write code that's easy to get right and easy to understand first. Then measure. And when you (somewhat surprisingly) found out this code is indeed the problem, see if it can be improved by changing. But only then.
Early implementations of C++ iostreams tended to be noticeably slower than their C counterparts. That hasn't been the case for quite a while though. Unless you're using a relatively old compiler/library, chances are they're pretty close to the same speed overall (though if you measure, you may find that one is faster than the other in some specific circumstance or other -- I've certainly seen a few such).
Bottom line: if you want to improve performance much, this probably isn't one of the first places to look.
My experience has been that iostreams have a huge amount of overhead due to locale logic. Of course you should profile to find out what the hot spots are, but I wouldn't be at all surprised to learn that formatted I/O was dragging down performance. –
Kitchener
In my experience, the question is not of performance, but capability. cout and cin have applications that fprintf and fscanf are very difficult to use. However, formatting is often easier with fprintf than cout. Concentrate on robustness and correctness before profiling.
For performance, block I/O is faster than formatted I/O. For example:
#include <iostream>
#include <cstdio>
using namespace std; // Because I'm lazy right now. :-)
int main(void)
{
static const char some_text[] = "This is kinda long, but anything will do.\n";
// The "fast" method using block writes:
cout.write(some_text,
sizeof(some_text) - sizeof('\0')); // Remove trailing nul from the length.
// The slow method, using formatted write:
cout << some_text;
// Using the C language techniques:
fwrite(some_text,
sizeof(some_text) - sizeof('\0'),
1,
stdout);
// Another fast method but slower than above:
puts(some_text);
// Finally, the slow method:
fprintf(stdout, some_text);
return 0;
}
When tuning a program's performance based on cout/cin vs. printf/scanf, one has to take into consideration that most of the time or bottleneck is not with the program but with the operating system. The operating system has a lot of overhead to manage when printing, such as resource management (is another task using the resource), switching contexts, etc. So if you want your program to run faster, use less I/O requests. If possible, combine several small requests into one large one.
Profiling is your friend; there's no one right answer, it depends on your specific usage pattern and platform.
Until you have profiled your code choosing one over the other amounts to nothing more than guessing. The best approach here is to pick the more usable function first. After later profiling reveals it to be a problem then switch to a provably faster function.
© 2022 - 2024 — McMap. All rights reserved.
assert that there should be no impact w/ a good compilerYou mean every version of GCC since 3.0 (About 2001 or about 9 years ago) iostreams is in the c++ standard lib which is dynamically loaded and thus does not affect application size. You should also try it (where am I going wrong? codepad.org/gu2M9Roj) – Odious