Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When I do large compilations (anywhere, but my question assumes Linux), many messages are often output to the screen. My question is, do these messages slow down the process? And if they do, does switching to a different tty so they aren't displayed to the screen reduce the performance hit?

share|improve this question
up vote 4 down vote accepted

Yes, they certainly can.


Run yes in an xterm, and you will see a lot of "y" lines swooshing past your eyes. Naturally, the yes process is able to generate "y" lines much faster than the xterm application is able to parse them, update its frame buffer, communicate with the X server in order to scroll the window and so on. How is it possible for these programs to cooperate?

The answer lies in blocking I/O. The pseudo terminal can only keep a certain amount of data inside its kernel buffer, and when that buffer is full and yes tries to call write(2), then write(2) will block, moving the yes process into the interruptible sleep state where it remains until the xterm process has had a chance to read off some of the buffered bytes.

The same thing happens if the TTY is connected to a serial port. yes would be able to transmit data at a much higher rate than, say, 9600 baud, but if the serial port is limited to that speed, the kernel buffer soon fills up and any subsequent write(2) calls block the process (or fail with the error code EAGAIN if the process has requested non-blocking I/O).

share|improve this answer
yes, but if the tty is not on screen, how is this buffer handled? this was my real question. is it written at a much faster rate? if not, why not? does the framebuffer or terminal process just consume at as fast a rate as possible? – Michael Lowman May 21 '11 at 17:19
Note that under windows console performance is limited to graphics card performance rates, and buffer size is configurable – Jim B May 21 '11 at 18:24
If the tty is in a gnu screen session you can control the blocking with the nonblock command. If you redirect STDOUT/STDERR to a file then you are subject to the blocking of the destination device. – toppledwagon May 21 '11 at 19:22

The way to speed up your compile if you are afraid of this is:

make >&/tmp/log.out & tail -f log.out
share|improve this answer

Your Answer


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.