Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I've found myself using the -v flag for lots of applications less and less (especially for trivial stuff like tar and cp). However, when I did and I was, say, unzipping a large file, it would take longer than when I didn't use the -v flag.

I assume this is because the terminal has to process the text and I'm filling up whatever buffer it might have. But my question is, does this make the application actually run slower or does it complete in the same amount of time and what I'm seeing is the terminal trying to catch up?

share|improve this question
    
Did you try to time e.g. tar xvf file.tar > /dev/null vs. tar xf file.tar? Redirecting to /dev/null should take your terminal out of this. –  Benjamin Bannier Jul 20 '11 at 17:03
3  
Also, note that stdout and stderr are line-buffered - meaning that filling up buffers doesn't take that long - it's the blocking printf calls (and by extension terminal output) that takes forever. –  new123456 Jul 20 '11 at 18:00
1  
If you had talked about Windows commands, I would say surely that it is true :) –  kokbira Jul 29 '11 at 12:22
    
For cpu intensive task, depending on how much IO you are doing, you may see horrible performance degradation. –  user Oct 1 at 16:27

5 Answers 5

up vote 24 down vote accepted

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.

share|improve this answer
    
Most programmers learns this pretty fast (Borland C in DOS) ;) –  Dragos Aug 3 '11 at 11:52
    
Of course if the console window is hidden (or even partially covered), then it won’t impact nearly as much as when the console is visible. Open a command-prompt and do a dir c:\/s/a. You can see the speed change when it is completely visible and partially covered. You can’t see it speed up when minimized, but it’s definitely faster, though you’d have to reboot if you wanted to test, in order to bypass the caching which would cause it to be faster anyway, since it wouldn’t have to access the disk. –  Synetech Aug 8 '11 at 6:05
1  
@Syn We're talking Linux here. –  Majenko Aug 8 '11 at 9:06
1  
@Matt it's still a valid comment. Please be respectful. –  nhinkle Aug 8 '11 at 20:30
    
@Matt, doh! I didn’t notice. (Maybe I got distracted from the DOS comment.) Anyway, Linux is quite different, but I wonder if the same holds true for it (visible consoles with lots of text scrolling running slower). –  Synetech Aug 9 '11 at 0:24

It depends on the aplication that you are running, however, generalizing, we can say that verbose will slow down the velocity of most common linux aplications (aplication must sincronyze them actions between stdout and I/O or processor bounds).

share|improve this answer

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.

share|improve this answer
3  
-1 this is just not true. printf() is insanely expensive –  Andreas Bonini Aug 14 '11 at 21:38
    
What I said was true. What you are trying to make it look like I said, however, is something else entirely. I am not saying anything about the efficiency of any specific stdlib printing. I am saying programs should be doing enough work that the time spent printing is negligible. Now go troll someone else. –  slarpspark Aug 24 '11 at 20:46
    
@slarpspark: it isn't necessarily negligible, even if we take printf() out of the equation, the stream of bytes still have to go through bash, then the terminal emulator, then the terminal emulator had to render the text into the screen after parsing the escape characters, and text-rendering isn't cheap if done at the rate that some verbose commands might do; and it would be especially expensive if the program flushes the output buffer at every line as that means context switches. I often experience while writing python scripts, that removing prints in tight loop sometimes can bring 10s to 1s. –  Lie Ryan Sep 8 '11 at 22:23

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

share|improve this answer

A verbose code is usually evaluated with an if instruction and every time it passes control to a display function the longer it takes, context can get switched, more interrupts.

But it depends, if you verbose code is a separate thread that is just checking the state of completion from time to time the difference is neglectable.

This question can benefit a lot from stackoverflow's experienced programmers contribution. I suggest moving :)

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.