Take the 2-minute tour ×

I know the basic functional differences between printf and sprintf. But, I would like to know about some timing/delay related differences between them both. Apparently, I want to use it in one my tasks for a custom built RTOS. What do you reckon ? I would like to know more how it would affect the performance of the system. (if any). Usually, I dont use print functions because of the massive delay but, I have to mandatorily use it here.

FYI, output is displayed on the terminal window using RS232.


share|improve this question
How do you want to compare to different functions? The one formats a string, the other prints a string via stdout. They should create the same text, but as they use it in different ways, you can't compare them. –  jeb Sep 28 '12 at 9:48
Btw. In some implementations both functions use the same common underlying helper function to format the text. –  jeb Sep 28 '12 at 9:53
I always answer questions about printf in embedded systems like this: why can't you write your own function that converts an integer to a string? It is very fundamental programming and will reduce the execution time and memory usage drastically. Now, if this is not just any embedded system, but a real-time embedded system, then forget about stdio.h. –  Lundin Sep 28 '12 at 13:04
@Lundin: That is rather too absolute. In an RTOS based application you might suggest avoiding the use of stdio in a real-time task with very short critical deadlines. Most applications also have low priority tasks without hard real-time constraints - that is often where you would perform slow and non-deterministic I/O operations that might block. Moreover the advisability of using stdio in real-time threads would depend on the actual constraints, whether stdout were buffered, and whether the implementation had baulking or timeout semantics rather than waiting indefinitely on a full buffer. –  Clifford Sep 28 '12 at 20:44
@Clifford Aside for the blatant difference in performance between your own 5 line function and printf, I think the current trend for real-time systems is more static analysis, more coding standards, more professionalism, less goofing around. The demands for MISRA-compatible libraries etc is only going to get more and more common. Since ensuring that something like the whole of stdio is MISRA-compliant will be a major pain. Writing a 5 line function will save you from that. –  Lundin Sep 29 '12 at 18:42
show 2 more comments

3 Answers

up vote 6 down vote accepted

The primary issue here is that printf() writes to stdout which can (and almost certainly will) block the calling thread. It's not at all uncommon on an embedded system for stdout to be a very slow RS232 port.

For this reason you never do this in a real-time thread as it rapidly becomes high non-real-time.

Writing into a buffer with sprintf() is fairly cheap (providing the buffer has already been allocated). It certainly doesn't block.

You'll probably find that your RTOS provides an asynchronous logging mechanism that can be called from a real-time thread without the risk of blocking. This is will be nothing more than a ring-buffer into which you write your terminal output and a lower priority thread to print it to the terminal.

share|improve this answer
Also, printf requires stdout and FILE* support. The C standard library implementation may not implement these for microcontrollers since many microcontroller applications don't have file systems, stdin, stdout etc. –  Josh Petitt Sep 28 '12 at 20:30
@Josh: A minimal implementation to support stdout/stdin usually requires just implementation of read()/write() functions only. The FILE structure is entirely contained within the stdio implementation. See newlib syscalls for example. –  Clifford Sep 28 '12 at 20:36
@Clifford, ah good to know. Since stdout is a FILE* I assumed you'd have to have FILE* support. With the microcontroller std libs I use (IAR and Red Suite) I link to the versions that don't implement printf or FILE* functions. –  Josh Petitt Sep 28 '12 at 21:11
@Josh: As you can see from the syscalls example, the only thing needed by the low-level read/write is the file handle (an int), this will be stored by stdio in a FILE structure, but stdin, stdout and stderr always have handles 0, 1 and 2 respectively so can be handles without fully implementing open/close/fstat etc. In teh example minimal stubs such operations simply return an error - a high-level fopen would return NULL. Of course mapping this into a file-system if you have one is also fairly straightforward. Keil has similar low level stubs (in retarget,c) and I am sure IAR does too. –  Clifford Sep 29 '12 at 7:47
add comment

Well ... All other things (which are unspecified) being equal, I guess sprintf() should be "faster" than printf(), since the former just writes to a in-memory buffer, while the latter writes to some I/O "device". Most devices will incur more delays than just writing to RAM will, which is why printf() is likely to be slower.

Those differences are probably quite minor though, the major issue is that most implementations do dynamic memory allocations which can be very expensive.

I would recommend stripping down your requirements so that you can implement them without using an off-the-shelf sprintf() implementation, or going through the code of the implementations you have to see if/when they do heap allocations.

share|improve this answer
Why a sprintf implementation should use dynamic allocations? The implementations I wrote/know use all only a small local buffer. –  jeb Sep 28 '12 at 9:45
add comment

sprintf() has no hardware dependencies, printf() is subject to your underlying low-level support for stdout. A naive implementation that pushes data to the UART and busy-waits for the transmit register or FIFO to become available would indeed have a "massive delay" as you say - but that would be a foolish implementation in a real-time system.

You would normally push the data to a ring-buffer, pipe or character queue, which is serviced by an interrupt routine. If the buffer is empty when you are about to push data to it, you would force the transmitter to start by buffering all but the first character then writing that directly to the UART. The UART interrupt will then keep the transmitter fed until the buffer is empty. From your application level, you are just writing data to memory, so the delay will be minimal and deterministic.

stdin can be implemented similarly, with the ISR writing and the application asynchronously reading.

By using an RTOS IPC mechanism such as a pipe or queue, or using synchronisation primitives such as semaphores you can implement blocking, baulking and timeout semantics on the data output.

If your UART supports DMA, you can potentially further reduce the interrupt rate and CPU overhead.

share|improve this answer
add comment

Your Answer


