1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Redirection vs. piping?

Discussion in 'Support' started by vefatica, Jun 18, 2015.

  1. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,939
    Likes Received:
    30
    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.

    Code:
    INT WINAPI NOOP ( LPWSTR psz )
    {
       return 0;
    }
    Code:
    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.
    Code:
    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
     
  2. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,854
    Likes Received:
    83
    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.
     
  3. samintz

    samintz Scott Mintz

    Joined:
    May 20, 2008
    Messages:
    1,187
    Likes Received:
    11
    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.
     
  4. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,939
    Likes Received:
    30
    NOOP does absolutely nothing except return. The child process that Rex spoke of exits immediately. You can do the same with, for example, ECHOS.
    Code:
    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.
    Code:
    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?
     
  5. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,854
    Likes Received:
    83
     

Share This Page