Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How fast are Linux pipes anyway? (2022)

mazzo.li

Post reply on HN
Print view View original

41–46 of 46 posts

Re: How fast are Linux pipes anyway? (2022)

#41

Post by asveikau »

manwe150 wrote: post #23
asveikau wrote: post #11

Earlier quoted context omitted.

Some years back Windows added AF_UNIX sockets, I wonder how those would perform relative to Win32 pipes. My guess is better.

Seems to reportedly be slightly faster in a few cases, but nothing particularly dramatic https://www.yanxurui.cc/posts/server/2023-11-28-benchmark-tc...

Are we reading the same tables? It seems to be about 3x faster than named pipes, and marginally faster than local TCP.

It's worth noting that in Win32, an unnamed pipe is just a named pipe with the name discarded. So this "3x faster" is, I think, the exact comparison we're interested in.

Re: How fast are Linux pipes anyway? (2022)

#42

Post by variadix »

klysm wrote: post #17
SoftTalker wrote: post #14

Earlier quoted context omitted.

Well POSIX only defines behavior, not performance. Every platform and OS will have its own performance idiosyncracies.

How on earth would POSIX define performance of something like pipes?

Some standards do define performance requirements, e.g. operations on data structures, in BigO notation.

Re: How fast are Linux pipes anyway? (2022)

#43

Post by yndoendo »

dataflow wrote: post #36
zh3 wrote: post #33

Earlier quoted context omitted.

Literally just having spare listening sockets, ready for incoming connections (and obv. not busy-waiting on them). Just reducing to the number actually in-use was the biggest speed-up - it was like Windows was busy-waiting internally for new connections (it wasn't a huge number either, something like 8 or 12).

By "spare listening sockets" do you mean having threads on the server calling ConnectNamedPipe? A bit confused by your terminology since these aren't called listening sockets. (You're not referring to socket() or AF_UNIX, right?) And yeah, that seems more or less what I expected. The implementation is probably optimized for repeated I/O on established connections, not repeated unestablished ones. Which would be simil…

Windows API is built on kludge of functionality, not performance. For example, GetPrivateProfileString [0] does exactly what you stated for files. Opens, parses a single key value, and closes. So much time and resources are wasted with the GetPrivateProfileXXXX APIs.

[0] https://learn.microsoft.com/en-us/windows/win32/api/winbase/...

Re: How fast are Linux pipes anyway? (2022)

#44

Post by dataflow »

yndoendo wrote: post #43
dataflow wrote: post #36

Earlier quoted context omitted.

By "spare listening sockets" do you mean having threads on the server calling ConnectNamedPipe? A bit confused by your terminology since these aren't called listening sockets. (You're not referring to socket() or AF_UNIX, right?) And yeah, that seems more or less what I expected. The implementation is probably optimized for repeated I/O on established connections, not repeated unestablished ones. Which would be simil…

Windows API is built on kludge of functionality, not performance. For example, GetPrivateProfileString [0] does exactly what you stated for files. Opens, parses a single key value, and closes. So much time and resources are wasted with the GetPrivateProfileXXXX APIs. [0] https://learn.microsoft.com/en-us/windows/win32/api/winbase/...

This function is provided only for compatibility with 16-bit Windows-based applications. Applications should store initialization information in the registry.

They literally provided the registry to solve this very problem from the days of 16-bit Windows. Holding it against them in 2025 when they have given you a perfectly good alternative for decades is rather ridiculous and is evidence for the exact opposite of what you intended.

Re: How fast are Linux pipes anyway? (2022)

#45

Post by yndoendo »

dataflow wrote: post #44
yndoendo wrote: post #43

Earlier quoted context omitted.

Windows API is built on kludge of functionality, not performance. For example, GetPrivateProfileString [0] does exactly what you stated for files. Opens, parses a single key value, and closes. So much time and resources are wasted with the GetPrivateProfileXXXX APIs. [0] https://learn.microsoft.com/en-us/windows/win32/api/winbase/...

This function is provided only for compatibility with 16-bit Windows-based applications. Applications should store initialization information in the registry. They literally provided the registry to solve this very problem from the days of 16-bit Windows. Holding it against them in 2025 when they have given you a perfectly good alternative for decades is rather ridiculous and is evidence for the exact opposite of wha…

This functionality is still used in software after 16-bit. It is even used by Skyrim software developers when it was "mark for compatibility by Microsoft". There is a project that hacked around this bad API [0]. You are going off the documentation wording versus real-world usage. Anyone that plays Skyrim today or in the future is still being harmed by this bad API.

INI files are 100% different than the Registry. I rather have an configuration file over registry entries because the registry is just another kluge of bad design. Configuration files are text files that are well defined.

Example would be the registry settings to mark a URL that it needs to run in IE compatibility mode because the source use old IE features that are now obsolete and don't even work in Edge or a modern browser. It should of just been a simple string array.

[0] https://www.nexusmods.com/skyrimspecialedition/mods/18860

Post reply on HN