Does running commands verbosely make them slower?

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

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

¹ In the case of a multithreaded application only the thread performing the debugging output will actually block.

It depends on the application that you are running. However, in general, we can say that verbose will slow down most common Linux applications as they must synchronize their actions between stdout and I/O or processor bounds.

Using yes as a test case on OS X 10.7, it seems it indeed matters if you print a lot of output to the terminal, as one would expect.

Quantifying this a little further, I ran yes for 5 seconds, in one case printing the output to the terminal and saving it to a file (with tee), in the other case doing the same except redirecting stdout to /dev/null:

1. yes | tee yeslog_term & sleep 5 && killall yes && wc -l yeslog_term
2. yes | tee yeslog_noterm > /dev/null & sleep 5 && killall yes && wc -l yeslog_noterm

Case 1. gives 2371584 lines and case 2. gives 136421376 lines, or 57 times more. The 'performance' of yes (as measured by the amount of lines it prints per unit time) is in this case thus 57 times slower.

One side note here is that I used yes in conjunction with tee here, which might influence the results slightly, however I do think the results are still valid.

Another indication that the program is slowed down is that running yes while outputting to a terminal, the terminal uses around 100% CPU and yes only around 37%, while running yes without outputting to a terminal it uses the full 100% (This is on a multi-core machine, so yes could use more CPU if it was able to, except it was slowed down by the terminal).

It is easy to just answer yes, it will slow down the application. But a much more true answer is it won't matter in 99% of the cases.

If your application is doing any kind of work that actually takes some CPU power, the chances of printing some extra lines of text onto the screen making any kind of difference is close to 0%.

In fact, you can easily make your own judgment: If the application is spewing out an immense wall of text, it might actually cost you a small bit. Maybe.