Redirection vs. piping?

[vefatica]

I asked about this a couple years ago but the discussion took a detour to third party apps and programming techniques. I'm not complaining but I'd like to understand why one example below (with the pipe) is faster than the other (with redirection). NOOP is a plugin.

INT WINAPI NOOP ( LPWSTR psz )
{
   return 0;
}

v:\> timer & dir /s c:\ > nul & timer
Timer 1 on: 00:23:54
Timer 1 off: 00:24:20  Elapsed: 0:00:26.24

v:\> timer & dir /s c:\ | noop & timer
Timer 1 on: 00:24:25
Timer 1 off: 00:24:41  Elapsed: 0:00:15.74

Even WC.EXE, which has to count lines, words, and characters is a lot better than redirecting to NUL.

v:\> timer & dir /s c:\ | wc & timer
Timer 1 on: 00:31:27
  Lines  Words  Chars
 243897  987074 14151559
Timer 1 off: 00:31:43  Elapsed: 0:00:16.08

 

[rconn]

Pipes create new processes; on a multicore processor you can have both the parent and the chid pipe process running full-speed simultaneously. And writing to a pipe is much faster than writing to a character device like NUL -- pipes get written in blocks and NUL is written character-by-character.

 

[samintz]

My initial guess is that NOOP is doing far less work than NUL is. Unless Rex is treating NUL as a special case, it is handled as a Windows device with all the overhead associated with that.

 

[vefatica]

NOOP does absolutely nothing except return. The child process that Rex spoke of exits immediately. You can do the same with, for example, ECHOS.

v:\> timer & dir /s c:\ > nul & timer
Timer 1 on: 12:05:10
Timer 1 off: 12:05:36  Elapsed: 0:00:26.10

v:\> timer & dir /s c:\ | echos & timer
Timer 1 on: 12:05:52
Timer 1 off: 12:06:08  Elapsed: 0:00:15.80

So what's happening when that child process exits ... TCC keeps writing data to some handle that no one's reading ... buffers fill up and are emptied to make room for more data?

Off-topic: Some batch files (often left over in %TEMP after a TCMD install) do this.

t:\> tail /n1 EXE77C8.tmp.bat
del "h:\Temp\EXE77C8.tmp.bat" | cls

What's the point of the pipe? When I run one of these (TCC or CMD), it DOES delete itself. Why do they hang around after an install ... aren't they run?

 

[rconn]

So what's happening when that child process exits ... TCC keeps writing data to some handle that no one's reading ... buffers fill up and are emptied to make room for more data?

No, you'll eventually (depending on the amount of RAM you have and how much output you've got) block the write, or get a pipe error. Data is never deleted until it's read.