Will printf still has a cost even I redirect output to /dev/null?












6















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.






c linux







share|improve this question


















  • 2





    Beware side effects: printf("%d", x=a+b); If you redirect to /dev/null side effects will happen; if you rewrite as a do nothing macro, side effects will be lost

    – pmg
    3 hours ago








  • 1





    Providing a myprintf(...) { return; } is probably what you want. You can then have a macro for printf forwarding to that method, preserving side effects yet not formatting any string or calling write

    – msrd0
    2 hours ago
















6















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.






c linux







share|improve this question


















  • 2





    Beware side effects: printf("%d", x=a+b); If you redirect to /dev/null side effects will happen; if you rewrite as a do nothing macro, side effects will be lost

    – pmg
    3 hours ago








  • 1





    Providing a myprintf(...) { return; } is probably what you want. You can then have a macro for printf forwarding to that method, preserving side effects yet not formatting any string or calling write

    – msrd0
    2 hours ago














6












6








6








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.






c linux







share|improve this question














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.






c linux




c linux






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked 3 hours ago









Michael PengMichael Peng

1089




1089








  • 2





    Beware side effects: printf("%d", x=a+b); If you redirect to /dev/null side effects will happen; if you rewrite as a do nothing macro, side effects will be lost

    – pmg
    3 hours ago








  • 1





    Providing a myprintf(...) { return; } is probably what you want. You can then have a macro for printf forwarding to that method, preserving side effects yet not formatting any string or calling write

    – msrd0
    2 hours ago














  • 2





    Beware side effects: printf("%d", x=a+b); If you redirect to /dev/null side effects will happen; if you rewrite as a do nothing macro, side effects will be lost

    – pmg
    3 hours ago








  • 1





    Providing a myprintf(...) { return; } is probably what you want. You can then have a macro for printf forwarding to that method, preserving side effects yet not formatting any string or calling write

    – msrd0
    2 hours ago








2




2





Beware side effects: printf("%d", x=a+b); If you redirect to /dev/null side effects will happen; if you rewrite as a do nothing macro, side effects will be lost

– pmg
3 hours ago







Beware side effects: printf("%d", x=a+b); If you redirect to /dev/null side effects will happen; if you rewrite as a do nothing macro, side effects will be lost

– pmg
3 hours ago






1




1





Providing a myprintf(...) { return; } is probably what you want. You can then have a macro for printf forwarding to that method, preserving side effects yet not formatting any string or calling write

– msrd0
2 hours ago





Providing a myprintf(...) { return; } is probably what you want. You can then have a macro for printf forwarding to that method, preserving side effects yet not formatting any string or calling write

– msrd0
2 hours ago












2 Answers
2






active

oldest

votes


















9














Pretty much.



Although in threory, the program could detect /dev/null and perform any optimization possible, based on general understanding of common implementations, they usually don't, nowadays. Below is the original answer.



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 fd 1 of the process. It's at the kernel level that the data isn't written to disk, but processed by the handler of the special device /dev/null (and then discarded). Therefore I see little improvement in terms of performance, unless your disk or terminal is very slow.



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






share|improve this answer





















  • 3





    Answers like this should state they are based on general understanding of common implementations and not upon specific documentation. In theory, there is no reason a C implementation might not inspect stdout, learn it is /dev/null, and suppress printf calls that do not contain %n and whose return value is not used. We cannot really assert nobody has done this, and students ought to learn the provenance of information since an important part of engineering is knowing how you know something (is it specified in a standard, is it just assumed, is it provable, and so on).

    – Eric Postpischil
    1 hour ago






  • 1





    @EricPostpischil Thanks for that! Very valuable information.

    – iBug
    1 hour ago



















5














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.






share|improve this answer





















  • 1





    @OP: Addition: You can further reduce the cost of printf() by creating a new driver which provides a new FILE * (depending on if your platform supports that). In this case, you can create a data sink which discards the data. The cost for formatting etc. still remains, but the OS call for writing to /dev/null goes away.

    – glglgl
    3 hours ago






  • 1





    Answers like this should state they are based on general understanding of common implementations and not upon specific documentation. In theory, there is no reason a C implementation might not inspect stdout, learn it is /dev/null, and suppress printf calls that do not contain %n and whose return value is not used. We cannot really assert nobody has done this, and students ought to learn the provenance of information since an important part of engineering is knowing how you know something (is it specified in a standard, is it just assumed, is it provable, and so on).

    – Eric Postpischil
    1 hour ago











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54196197%2fwill-printf-still-has-a-cost-even-i-redirect-output-to-dev-null%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes









9














Pretty much.



Although in threory, the program could detect /dev/null and perform any optimization possible, based on general understanding of common implementations, they usually don't, nowadays. Below is the original answer.



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 fd 1 of the process. It's at the kernel level that the data isn't written to disk, but processed by the handler of the special device /dev/null (and then discarded). Therefore I see little improvement in terms of performance, unless your disk or terminal is very slow.



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






share|improve this answer





















  • 3





    Answers like this should state they are based on general understanding of common implementations and not upon specific documentation. In theory, there is no reason a C implementation might not inspect stdout, learn it is /dev/null, and suppress printf calls that do not contain %n and whose return value is not used. We cannot really assert nobody has done this, and students ought to learn the provenance of information since an important part of engineering is knowing how you know something (is it specified in a standard, is it just assumed, is it provable, and so on).

    – Eric Postpischil
    1 hour ago






  • 1





    @EricPostpischil Thanks for that! Very valuable information.

    – iBug
    1 hour ago
















9














Pretty much.



Although in threory, the program could detect /dev/null and perform any optimization possible, based on general understanding of common implementations, they usually don't, nowadays. Below is the original answer.



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 fd 1 of the process. It's at the kernel level that the data isn't written to disk, but processed by the handler of the special device /dev/null (and then discarded). Therefore I see little improvement in terms of performance, unless your disk or terminal is very slow.



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






share|improve this answer





















  • 3





    Answers like this should state they are based on general understanding of common implementations and not upon specific documentation. In theory, there is no reason a C implementation might not inspect stdout, learn it is /dev/null, and suppress printf calls that do not contain %n and whose return value is not used. We cannot really assert nobody has done this, and students ought to learn the provenance of information since an important part of engineering is knowing how you know something (is it specified in a standard, is it just assumed, is it provable, and so on).

    – Eric Postpischil
    1 hour ago






  • 1





    @EricPostpischil Thanks for that! Very valuable information.

    – iBug
    1 hour ago














9












9








9







Pretty much.



Although in threory, the program could detect /dev/null and perform any optimization possible, based on general understanding of common implementations, they usually don't, nowadays. Below is the original answer.



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 fd 1 of the process. It's at the kernel level that the data isn't written to disk, but processed by the handler of the special device /dev/null (and then discarded). Therefore I see little improvement in terms of performance, unless your disk or terminal is very slow.



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






share|improve this answer















Pretty much.



Although in threory, the program could detect /dev/null and perform any optimization possible, based on general understanding of common implementations, they usually don't, nowadays. Below is the original answer.



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 fd 1 of the process. It's at the kernel level that the data isn't written to disk, but processed by the handler of the special device /dev/null (and then discarded). Therefore I see little improvement in terms of performance, unless your disk or terminal is very slow.



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







share|improve this answer














share|improve this answer



share|improve this answer








edited 1 hour ago

























answered 3 hours ago









iBugiBug

19.4k53362




19.4k53362








  • 3





    Answers like this should state they are based on general understanding of common implementations and not upon specific documentation. In theory, there is no reason a C implementation might not inspect stdout, learn it is /dev/null, and suppress printf calls that do not contain %n and whose return value is not used. We cannot really assert nobody has done this, and students ought to learn the provenance of information since an important part of engineering is knowing how you know something (is it specified in a standard, is it just assumed, is it provable, and so on).

    – Eric Postpischil
    1 hour ago






  • 1





    @EricPostpischil Thanks for that! Very valuable information.

    – iBug
    1 hour ago














  • 3





    Answers like this should state they are based on general understanding of common implementations and not upon specific documentation. In theory, there is no reason a C implementation might not inspect stdout, learn it is /dev/null, and suppress printf calls that do not contain %n and whose return value is not used. We cannot really assert nobody has done this, and students ought to learn the provenance of information since an important part of engineering is knowing how you know something (is it specified in a standard, is it just assumed, is it provable, and so on).

    – Eric Postpischil
    1 hour ago






  • 1





    @EricPostpischil Thanks for that! Very valuable information.

    – iBug
    1 hour ago








3




3





Answers like this should state they are based on general understanding of common implementations and not upon specific documentation. In theory, there is no reason a C implementation might not inspect stdout, learn it is /dev/null, and suppress printf calls that do not contain %n and whose return value is not used. We cannot really assert nobody has done this, and students ought to learn the provenance of information since an important part of engineering is knowing how you know something (is it specified in a standard, is it just assumed, is it provable, and so on).

– Eric Postpischil
1 hour ago





Answers like this should state they are based on general understanding of common implementations and not upon specific documentation. In theory, there is no reason a C implementation might not inspect stdout, learn it is /dev/null, and suppress printf calls that do not contain %n and whose return value is not used. We cannot really assert nobody has done this, and students ought to learn the provenance of information since an important part of engineering is knowing how you know something (is it specified in a standard, is it just assumed, is it provable, and so on).

– Eric Postpischil
1 hour ago




1




1





@EricPostpischil Thanks for that! Very valuable information.

– iBug
1 hour ago





@EricPostpischil Thanks for that! Very valuable information.

– iBug
1 hour ago













5














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.






share|improve this answer





















  • 1





    @OP: Addition: You can further reduce the cost of printf() by creating a new driver which provides a new FILE * (depending on if your platform supports that). In this case, you can create a data sink which discards the data. The cost for formatting etc. still remains, but the OS call for writing to /dev/null goes away.

    – glglgl
    3 hours ago






  • 1





    Answers like this should state they are based on general understanding of common implementations and not upon specific documentation. In theory, there is no reason a C implementation might not inspect stdout, learn it is /dev/null, and suppress printf calls that do not contain %n and whose return value is not used. We cannot really assert nobody has done this, and students ought to learn the provenance of information since an important part of engineering is knowing how you know something (is it specified in a standard, is it just assumed, is it provable, and so on).

    – Eric Postpischil
    1 hour ago
















5














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.






share|improve this answer





















  • 1





    @OP: Addition: You can further reduce the cost of printf() by creating a new driver which provides a new FILE * (depending on if your platform supports that). In this case, you can create a data sink which discards the data. The cost for formatting etc. still remains, but the OS call for writing to /dev/null goes away.

    – glglgl
    3 hours ago






  • 1





    Answers like this should state they are based on general understanding of common implementations and not upon specific documentation. In theory, there is no reason a C implementation might not inspect stdout, learn it is /dev/null, and suppress printf calls that do not contain %n and whose return value is not used. We cannot really assert nobody has done this, and students ought to learn the provenance of information since an important part of engineering is knowing how you know something (is it specified in a standard, is it just assumed, is it provable, and so on).

    – Eric Postpischil
    1 hour ago














5












5








5







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.






share|improve this answer















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.







share|improve this answer














share|improve this answer



share|improve this answer








edited 2 hours ago

























answered 3 hours ago









Some programmer dudeSome programmer dude

296k24250411




296k24250411








  • 1





    @OP: Addition: You can further reduce the cost of printf() by creating a new driver which provides a new FILE * (depending on if your platform supports that). In this case, you can create a data sink which discards the data. The cost for formatting etc. still remains, but the OS call for writing to /dev/null goes away.

    – glglgl
    3 hours ago






  • 1





    Answers like this should state they are based on general understanding of common implementations and not upon specific documentation. In theory, there is no reason a C implementation might not inspect stdout, learn it is /dev/null, and suppress printf calls that do not contain %n and whose return value is not used. We cannot really assert nobody has done this, and students ought to learn the provenance of information since an important part of engineering is knowing how you know something (is it specified in a standard, is it just assumed, is it provable, and so on).

    – Eric Postpischil
    1 hour ago














  • 1





    @OP: Addition: You can further reduce the cost of printf() by creating a new driver which provides a new FILE * (depending on if your platform supports that). In this case, you can create a data sink which discards the data. The cost for formatting etc. still remains, but the OS call for writing to /dev/null goes away.

    – glglgl
    3 hours ago






  • 1





    Answers like this should state they are based on general understanding of common implementations and not upon specific documentation. In theory, there is no reason a C implementation might not inspect stdout, learn it is /dev/null, and suppress printf calls that do not contain %n and whose return value is not used. We cannot really assert nobody has done this, and students ought to learn the provenance of information since an important part of engineering is knowing how you know something (is it specified in a standard, is it just assumed, is it provable, and so on).

    – Eric Postpischil
    1 hour ago








1




1





@OP: Addition: You can further reduce the cost of printf() by creating a new driver which provides a new FILE * (depending on if your platform supports that). In this case, you can create a data sink which discards the data. The cost for formatting etc. still remains, but the OS call for writing to /dev/null goes away.

– glglgl
3 hours ago





@OP: Addition: You can further reduce the cost of printf() by creating a new driver which provides a new FILE * (depending on if your platform supports that). In this case, you can create a data sink which discards the data. The cost for formatting etc. still remains, but the OS call for writing to /dev/null goes away.

– glglgl
3 hours ago




1




1





Answers like this should state they are based on general understanding of common implementations and not upon specific documentation. In theory, there is no reason a C implementation might not inspect stdout, learn it is /dev/null, and suppress printf calls that do not contain %n and whose return value is not used. We cannot really assert nobody has done this, and students ought to learn the provenance of information since an important part of engineering is knowing how you know something (is it specified in a standard, is it just assumed, is it provable, and so on).

– Eric Postpischil
1 hour ago





Answers like this should state they are based on general understanding of common implementations and not upon specific documentation. In theory, there is no reason a C implementation might not inspect stdout, learn it is /dev/null, and suppress printf calls that do not contain %n and whose return value is not used. We cannot really assert nobody has done this, and students ought to learn the provenance of information since an important part of engineering is knowing how you know something (is it specified in a standard, is it just assumed, is it provable, and so on).

– Eric Postpischil
1 hour ago


















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid …



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54196197%2fwill-printf-still-has-a-cost-even-i-redirect-output-to-dev-null%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







-

Popular posts from this blog

Knooppunt Holsloot

Image
Knooppunt Holsloot Kenmerken Wegen A37 × N34 Type knooppunt klaverblad Portaal     Verkeer & Vervoer Knooppunt Holsloot is een verkeersknooppunt op de kruising van de autosnelweg A37 en de N34 in Drenthe, tussen Emmen en Coevorden. Oorspronkelijk was deze aansluiting een afritconstructie van het type Haarlemmermeeraansluiting, zoals bij Knooppunt Hooipolder. Sinds 2002 is het knooppunt omgebouwd tot een volledig klaverblad. Als noviteit werd hier voor het eerst gebruikgemaakt van dimbare verlichting in plaats van de normale vaste tijden waarop de verlichting aan en uit gaat, wat een grote kostenbesparing opleverde. [1] Dat Holsloot als volwaardig knooppunt is uitgevoerd, waarbij alle verkeersstromen en afbuigingen ononderbroken kunnen doorgaan, is uitzonderlijk. Het betreft hier namelijk een aansluiting tussen een autosnelweg en niet-snelweg. Een vergelijkbare situatie treft men nabij Hoensbroek bij het knooppunt Ten Esschen.     Aa
Read more

Altaar (religie)

Image
Deel van de serie over kerkelijk gerei waaronder paramenten en liturgisch vaatwerk gebruikt in de liturgie Liturgisch vaatwerk Vasa sacra Miskelk · Pateen Kelklepeltje Ciborie · Monstrans Pyxis · Custodiale Vasa non sacra Ampullen · Wijwatervat Olievaatje Wierookvat · Ablutievat Paramenten Amict · Albe · Baarkleed · Cingel Tuniek · Dalmatiek · Fanon Kazuifel · Manipel · Stola Gremiale · Benedictievelum Mijter Koorkledij Rochet · Superplie Koorkap · Cappa magna Kovel Kelkgerei Bursa · Kelkvelum Ciborievelum Kerklinnen Corporale · Kelkdoekje Lavabodoekje · Palla Altaardwaal Kerkinterieur Altaar · Ambo Biechtstoel · Communiebank Doksaal · Doopvont Faldistorium Godslamp · Hoogaltaar Heilig Kruisaltaar Katheder · Preekstoel Sedilia Tabernakel · Volksaltaar Liturgische boeken Altaarmissaal Benedictionale · Brevier Evangeliarium · Evangelistarium Graduale · Kyriale Lectionarium Psalter · Rituaal Sacramentarium · Volksmissaal Overige Flambou
Read more

Gregoriusmis

Image
Een afbeelding van de Gregoriusmis uit een getijdenboek gemaakt in de zuidelijke Nederlanden tussen 1500 en 1525 Gregoriusmis, Meester van het Akense Altaar, ca. 1500-1525. Collectie Museum Catharijneconvent De Gregoriusmis of de Mis van Sint Gregorius is een motief in katholieke kunst, dat het eerst verscheen in de late Middeleeuwen en dat nog steeds werd gebruikt tijdens de contrareformatie. Paus Gregorius I (ca. 540-604) is afgebeeld, de H. Mis opdragend, terwijl Christus als de Man van Smarten verschijnt op het altaar dat voor Sint Gregorius staat. Volgens de legende had St. Gregorius gebeden om een teken voor een betwijfelaar van de transsubstantiatieleer, waarop de lijdende Christus tijdens het opdragen van de Mis verscheen om hem te overtuigen en waarbij zijn bloed in de altaarkelk liep. Vaak zijn ook de passiewerktuigen afgebeeld. Zie de categorie Mass of Saint Gregory van Wikimedia Commons voor mediabestanden over dit onderwerp. This page is onl
Read more