How fast are Linux pipes anyway? (2022)
1–10 of 46 posts
Re: How fast are Linux pipes anyway? (2022)
#2I feel bad that this doesn't have any comments, the article was really great.
I'd like to use splice more, but the end of the article talked about the security implications and some ABI breaking.
I'm curious to know if long term plans are to keep splice around?
I'd also be curious how hard it would be to patch the default pipe to always use splice for performance improvements.
Re: How fast are Linux pipes anyway? (2022)
#3Great article, discussed previously on HN:
https://news.ycombinator.com/item?id=31592934 (200 comments)
https://news.ycombinator.com/item?id=37782493 (105 comments)
Re: How fast are Linux pipes anyway? (2022)
#4I feel bad that this doesn't have any comments, the article was really great. I'd like to use splice more, but the end of the article talked about the security implications and some ABI breaking. I'm curious to know if long term plans are to keep splice around? I'd also be curious how hard it would be to patch the default pipe to always use splice for performance improvements.
For more comments, see: https://news.ycombinator.com/item?id=44347412
Re: How fast are Linux pipes anyway? (2022)
#5This is such a dope article. I love that it comes from time to time.
Re: How fast are Linux pipes anyway? (2022)
#6(2022)
Re: How fast are Linux pipes anyway? (2022)
#7Seared into my soul is the experience porting a linux pipe-based application to Windows, thinking it's all posix and given it's all in memory the performance will be more or less the same. The performance was hideous, even after we found that having pipes waiting for a connection more or less ground windows to a halt.
Some years later this got revisited due to needing to use the same thing under C# on Win10 and while it was better it was still a major embarrassment how big the performance gap was.
Re: How fast are Linux pipes anyway? (2022)
#8FWIW there is readv() / writev(), splice(), sendfile(), funopen(), and io_buffer() as well.
splice() is great when transferring data between pipes and UNIX sockets with zero-copy, but it is Linux-only.
splice() is the fastest and most efficient way to transfer data through pipes (on Linux), especially for large volumes. It bypasses memory allocations in userspace (as opposed to read(v)/write(v)), there is no extra buffer management logic, there is no memcpy() or iovec traversal.
Sadly on BSDs, for pipes, readv() / writev() is the most performant way to achieve the same if I am not mistaken. Please correct me if I am wrong.
At any rate, this is a great article.
Re: How fast are Linux pipes anyway? (2022)
#9FWIW there is readv() / writev(), splice(), sendfile(), funopen(), and io_buffer() as well. splice() is great when transferring data between pipes and UNIX sockets with zero-copy, but it is Linux-only. splice() is the fastest and most efficient way to transfer data through pipes (on Linux), especially for large volumes. It bypasses memory allocations in userspace (as opposed to read(v)/write(v)), there is no extra bu…
> sendfile() is file-to-socket (zero-copy as well), and has very high performance as well, for both Linux and BSDs. It only supports file-to-socket, however, and well, to stay relevant, sendmsg() can't be used with pipes in the general case, it is for UNIX domain sockets, INET sockets, and other socket types.
On Linux, sendfile supports more than just file to socket, as it's implemented using splice. I've used it for file-to-block-device in the past.
Re: How fast are Linux pipes anyway? (2022)
#10Seared into my soul is the experience porting a linux pipe-based application to Windows, thinking it's all posix and given it's all in memory the performance will be more or less the same. The performance was hideous, even after we found that having pipes waiting for a connection more or less ground windows to a halt. Some years later this got revisited due to needing to use the same thing under C# on Win10 and while…
Did you find that you needed interprocess communication to replace the gap?