I heard from credible sources that C language's printf(...) funtion has a/some big disadvantage(s) particularly in real-time coding. I wasn't in a position to ask the sources directly so I embarked on a research to find out what it is. As much as i tried I couldn't find anyone discusing this on the net.
Deos anyone know what this disadvantages are?
XX
printf disadvantages?
printf needs to scan the format string and construct the output dynamically. Not only that, but a variadic argument list needs evaluation, too.
However, speed is not your biggest concern. Potential buffer overflows is the real danger, particularly bad (or mismatched) format specifiers. The latter is generally known as "uncontrolled format strings", which can be exploited in creative ways if you are not careful.
However, speed is not your biggest concern. Potential buffer overflows is the real danger, particularly bad (or mismatched) format specifiers. The latter is generally known as "uncontrolled format strings", which can be exploited in creative ways if you are not careful.
What is your definition of "real time coding"? What alternatives are you considering? Who is this credible source, who makes vague assertions without the detail to back them up?
printf's main disadvantages, IMO, are the burden it places on the programmer to ensure the format string matches the set of parameters, and the fact that you are dealing with a C string API - all the usual security/bug warnings apply.
printf's main disadvantages, IMO, are the burden it places on the programmer to ensure the format string matches the set of parameters, and the fact that you are dealing with a C string API - all the usual security/bug warnings apply.
the matrix screen saver......
Seriously though
if you mean that using printf or some self implemented variant to render debug text to a console in a game engine is a bad idea. Yes and no. warning messages detailing a function failing.. good. Rendering information using printf style eplisis (...) set of arguments per frame. your performance will drop miserably.
so yeah, good and bad.
Seriously though
if you mean that using printf or some self implemented variant to render debug text to a console in a game engine is a bad idea. Yes and no. warning messages detailing a function failing.. good. Rendering information using printf style eplisis (...) set of arguments per frame. your performance will drop miserably.
so yeah, good and bad.
Rendering information using printf style eplisis (...) set of arguments per frame. your performance will drop miserably.
Unfounded superstition, at best.
Go ahead. Write a program that calls sprintf() in a tight loop. Benchmark it. Let me know how "miserably" it performs.
For objectivity, compare to std::stringstream and other solutions for formatted output. Definitely include boost's formatted output library, because that one is dog slow.
But please don't spread this kind of rumor without any evidence or backup.
(For the record, I know you are wrong because I've seen variadic functions used for debug logging, framerate counters, and all manner of other per-frame operations and unless you do something idiotic like try to write an ASCII rasterizer using a printf() call per character, they are not the killer of performance you make them out to be.)
I would think that the performance issues would be related to whatever mechanism is used by the system to actually output the resulting string.
I've heard of a situation on a game console in which printf was directed to the debug window which was on a remote machine, and something about printing a lot of information over the network caused a problem.
I'm not sure what the exact issue was, but the point is that printf() is an output function, which carries some sort of output overhead, and is rarely ever appropriate for use by a real-time system.
I've heard of a situation on a game console in which printf was directed to the debug window which was on a remote machine, and something about printing a lot of information over the network caused a problem.
I'm not sure what the exact issue was, but the point is that printf() is an output function, which carries some sort of output overhead, and is rarely ever appropriate for use by a real-time system.
To be excessively pedantic, and expound on VReality's point a bit: the problem is doing something silly like spamming 2MB/s of logs across the network (or to disk, or the console, or anything else). It doesn't matter if you use printf() or cout or foo for any value of foo. What really matters is the nature of the activity, more so than the function being used.
You'll note I talked about sprintf() and not printf(). printf() is designed to write to stdout, which might be the console, or piped to another process, or routed across a network into another country, or whatever. My point is that variadic functions are not inherently performance problems when considered in the context of, say, rendering text. The cost of drawing the actual text to the screen is going to be orders of magnitude higher than the cost of calling sprintf(). And the same follows for printf() itself, or fprintf(), or anything else: the expense is the nature of the operation, not the variable number of arguments.
You'll note I talked about sprintf() and not printf(). printf() is designed to write to stdout, which might be the console, or piped to another process, or routed across a network into another country, or whatever. My point is that variadic functions are not inherently performance problems when considered in the context of, say, rendering text. The cost of drawing the actual text to the screen is going to be orders of magnitude higher than the cost of calling sprintf(). And the same follows for printf() itself, or fprintf(), or anything else: the expense is the nature of the operation, not the variable number of arguments.
I was ouputting from many points in my physics calcs per frame and my fps chunked down hard. the enitre game slowed considerably. it may have also been extra memory allocations occurring to field the ever expanding list of string forming console history.
I was heavily using my own custom variadic printf function to render debug info in GL on iOS. I had no problem on that front. In fact the bottleneck was actually rendering the glyphs in GL as opposed to constructing the string in the custom printf. And that was on a feeble ARM processor.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
