Jump to content
  • Advertisement
Sign in to follow this  
run_g

printf disadvantages?

This topic is 2644 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.)




Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!