3

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?

Michael Lowman
  • 3,604
  • 20
  • 36

2 Answers2

4

Yes, they certainly can.

From http://www.linuxakesson.net/programming/tty/index.php

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

toppledwagon
  • 4,245
  • 25
  • 15
  • 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
2

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

make >&/tmp/log.out & tail -f log.out
Seth Robertson
  • 1,119
  • 6
  • 10