Tukukkk

We have a daemon contains a lot of print message. Since we working on a embedded device with a weak CPU and other constraint hardware, we want to minimize any kinds of costs(IO, CPU,etc..) of printf message in our final version. (Users don't have a console)

My teammates and I have a disagreement. He think we can just redirect everything to /dev/null. It won't cost any IO so affections will be minimal. But I think it will still cost CPU and we better define a macro for printf so we can rewrite "printf"(maybe just return).

So I need some opinions about who is right. Will Linux smart enough to optimize printf? I really doubt it.

Pretty much.

Although in theory, the program could detect /dev/null and perform some optimizations within the restrictions of standards they comply to, based on general understanding of common implementations, they practically don't (i.e. I am unaware of any Unix or Linux system doing so). You can read Damon's answer for details about POSIX standard requirements.

When you redirect the stdout of the program to /dev/null, any call to printf(3) will still evaluate all the arguments (beware side effects like a++), and the string formatting will still take place before calling write(2), which writes the full formatted string to the standard output of the process. It's at the kernel level that the data isn't written to disk, but discarded by the handler associated with the special device /dev/null. Therefore I see little improvement in terms of performance, unless your disk or terminal is considerably slow. Disk and RAM capacity (for terminals) may be another concern, though.

Be aware that if you replace printf completely, some side effects may go wrong, for example printf("%d%n", a++, &b).

The printf function writes to stdout. If the file descriptor connected to stdout is redirected to /dev/null then no output will be written anywhere (but it will still be written), but the call to printf itself and the formatting it does will still happen.

Generally speaking, an implementation is permitted to perform such optimisations if they do not affect the observable (functional) outputs of the program. In the case of printf(), that would mean that if the program doesn't use the return value, and if there are no %n conversions, then the implementation would be allowed to do nothing.

In practice, I'm not aware of any implementation on Linux that currently (early 2019) performs such an optimisation - the compilers and libraries I'm familiar with will format the output and write the result to the null device, relying on the kernel' to ignore it.

You may want to write a forwarding function of your own if you really need to save the cost of formatting when the output is not used - you'll want to it to return void, and you should check the format string for %n. (You could use snprintf with a NULL and 0 buffer if you need those side-effects, but the savings are unlikely to repay the effort invested).

The printf function will write to stdout. It is not conforming to optimize for /dev/null.
Therefore, you will have the overhead of parsing the format string and evaluating any necessary arguments, and you will have at least one syscall, plus you will copy a buffer to kernel address space (which, compared to the cost of the syscall is neglegible).

This answer is based on the specific documentation of POSIX.

System Interfaces

dprintf, fprintf, printf, snprintf, sprintf - print formatted output

The fprintf() function shall place output on the named output stream. The printf() function shall place output on the standard output stream stdout. The sprintf() function shall place output followed by the null byte, '', in consecutive bytes starting at *s; it is the user's responsibility to ensure that enough space is available.

Base Definitions

shall

For an implementation that conforms to POSIX.1-2017, describes a feature or behavior that is mandatory. An application can rely on the existence of the feature or behavior.