title: What are the main disadvantages of Windows pipes for inter-process communication?
body: <p>Say you are splitting a monolithic Windows program into reusable components which could communicate with each other using some sort of <a href="http://msdn.microsoft.com/en-gb/library/windows/desktop/aa365574%28v=vs.85%29.aspx" rel="noreferrer">inter-process communication</a> (IPC), and, for whatever the reason, you choose anonymous pipes (e.g. starting a number of Process-es and connecting Console.Out to Console.In of the next process, or just using "|" in the command prompt).</p>
  
  <p>A Dr. Dobbs article with an example <a href="http://www.drdobbs.com/windows/using-named-pipes-to-connect-a-gui-to-a/231903148" rel="noreferrer">with named pipes</a>: </p>
  
  <p>What would be the performance penalty compared to other IPC methods within the same machine? And what would be the first problem to hit when scaling up in the number of processes or the amount of data being transmitted?</p>
  
  <p>E.g. If instead of pipes we were using files we would hit locking issues and disk speed.</p>
  
  <p>Note that by having to serialise the data structures being transmitted there is already an overhead, which is my baseline for loss of efficiency.</p>
  
  <p>PS. The interest in pipes is because they are easy to implement in each process (Console.Readline, Console.WriteLine), it's easy to write MSMQ and async HTTP interfaces to them, and for the love of Unix and the command line.</p>