←back to thread

Using gRPC for (local) inter-process communication (2021)

(www.mpi-hd.mpg.de)
112 points zardinality | 1 comments | 20 Nov 24 13:42 UTC | HN request time: 0.199s | source
Show context
jeffbee ◴[20 Nov 24 15:59 UTC] No.42195134[source]▶
Interesting that it is taken on faith that unix sockets are faster than inet sockets.
replies(5): >>42195458 #>>42195476 #>>42195489 #>>42195960 #>>42196345 #
eqvinox ◴[20 Nov 24 16:25 UTC] No.42195489[source]▶
That's because it's logical that implementing network capable segmentation and flow control is more costly than just moving data with internal, native structures. And looking up random benchmarks yields anything from equal performance to 10x faster for Unix domain.
replies(1): >>42196875 #
bluGill ◴[20 Nov 24 18:41 UTC] No.42196875[source]▶
It wouldn't surprise me if inet sockets were more optimized though and so unix sockets ended up slower anyway just because nobody has bothered to make them good (which is probably why some of your benchmarks show equal performance). Benchmarks are important.
replies(2): >>42196928 #>>42198265 #
1. sgtnoodle ◴[20 Nov 24 21:23 UTC] No.42198265[source]▶
I've spent several years optimizing a specialized IPC mechanism for a work project. I've spent time reviewing the Linux Kernel's unix socket source code to understand obscure edge cases. There isn't really much to optimize - it's just copying bytes between buffers. Most of the complexity of the code has to do with permissions and implementing the ability to send file descriptors. All my benchmarks have unambiguously showed unix sockets to be more performant than loopback TCP for my particular use case.