Yes, running verbose will slow down your applications.
How much depends on the application.
Every print to the terminal will require extra processing time. In the case of using printf() or any of its sisters, this is quite a heavy amount of processing wasted.
Also, the terminal has to deal with that data. There is a limited amount of buffer space between the application and the terminal, and the IO channel will block until there is enough space in said buffer to actually output the data. The application will generally not be able to continue while this blocking is taking place.1
Also, the act of displaying the debugging text on the terminal will be consuming processing cycles. Again, this is dependent on both the application (the quantity of debugging), the terminal program (fonts used, effects, etc) and even the X windows driver in use (hardware acceleration, etc).
The time
program can be used to fairly accurately determine how long a command has taken to run. Running the same program twice through time, once with debugging, and once without, will show you how much difference it makes. I would suggest running the command once before performing the tests to ensure that the caching is the same for both test runs of the command. You don't want to skew the results by having the second run go much faster because most of the data was cached by the first run now do you...
1 In the case of a multithreaded application only the thread performing the debugging output will actually block.
tar xvf file.tar > /dev/null
vs.tar xf file.tar
? Redirecting to/dev/null
should take your terminal out of this.stdout
andstderr
are line-buffered - meaning that filling up buffers doesn't take that long - it's the blockingprintf
calls (and by extension terminal output) that takes forever.