How slow are TCP sockets compared to named pipes on Windows for localhost IPC?

It will be the same (or at least not measurably different). Winsock is smart enough to know if it's talking to a socket on the same host and, in that case, it will short-circuit pretty much everything below IP and copy data directly buffer-to-buffer. In terms of named pipes vs. sockets, if you need to potentially be able to communicate to different machines ever in the future, choose sockets. If you know for a fact that you'll never need to do that, pick whichever one your developers are most familiar or most comfortable with.

For anyone that comes to read this later, I want to add some findings that answer the original question.

For a utility we are developing we have a networking class that can use named pipes, or TCP with the same calls.

Here is a typical loop back file transfer on our test system:

TCP/IP Transfer time: 2.5 Seconds
Named Pipes Transfer time: 3.1 Seconds

Now, if you go outside the machine and connect to a remote computer on your network the performance for named pipes is much worse:

TCP/IP Transfer time: 12 Seconds
Named Pipes Transfer time: 2.5 Minutes (Yes Minutes!)

I realize that this is just one system (Windows 7) But I think it is a good indicator of how slow named pipes can be...and it seems like TCP is the way to go.

I know this topic is very old, but it was still relevant for me, and maybe others will look at this in the future as well.

I implemented IPC between Excel (VBA) and another process on the same machine, both via a TCP connection as well as via Named Pipes.

In a quick performance test, I submitted a message than consisted of 26 bytes from client (Excel) to server (not Excel), and waited for the reply message from the other process (which consisted of 12 bytes in the example).I executed this a ton of times in a loop and measured the average execution time.

With TCP on localhost (Windows 7, no fastpath), one "conversation" (request+reply) took around 300-350 microseconds. Especially sending data was quite slow (sending the 26 bytes took around 200microseconds via TCP).With Named Pipes, one conversation took around 60 microseconds on average - so a LOT faster.

I'm not entirely sure why the difference was so large. The corporate environment I tested this in has a strict firewall, package inspections and what not, so I THINK this may have been caused as even the localhost-based TCP connection went through security measures significantly slowing it down, while named pipe ones likely did not.

TL:DR: In my case, Named Pipes were around 5-6 times faster than TCP for small packages (have not tested with bigger ones yet)