1. 25
  1.  

  2. 2

    This may have some impact on Windows (because they have core architectural mistakes that make processes take up to 100 milliseconds to spin up)

    Do you happen to have a link with more details on this? I’ve heard that Windows is slow for processes/IO several times and I’d be curious to know why (and why they can’t fix it in a backwards-compatible way).

    1. 5

      There are a number of highly upvoted answers here but it’s hard for me to distill anything. It may be that these aren’t good answers.

      https://stackoverflow.com/questions/47845/why-is-creating-a-new-process-more-expensive-on-windows-than-linux

      1. 6

        I think these are good answers, but I’ve had a lot of exposure to Windows internals.

        What they’re saying is that the barebones NT architecture isn’t slow to create processes. But the vast majority of people are running Win32+NT programs, and Win32 behavior brings in a fair amount of overhead. Win32 has a lot of expected “startup” behavior which Unix is not obliged to do. In practice this isn’t a big deal because a native Win32 app will use multithreading instead of multiprocessing.

        1. 3

          I don’t think that is strictly correct. WSLv1 processes are NT processes without Win32 but still spawn relatively slowly.

          1. 3

            Hm, I remember WSLv1 performance issues mostly being tied to the filesystem implementation. This thread says WSLv1 process start times were fast, but they probably mean relative to Win32.

            I suspect an optimized pico process microbenchmark would perform competitively, but I’m just speculating. The vast majority of Win32 process-start slowdown comes from reloading all those DLLs, reading the registry, etc. That is the “core architectural mistakes” I believe the OP is talking about.

      2. 4

        I don’t remember for sure where I saw this, but it may have been in the WSL1 devlogs? Either way I may have been wrong about the order of magnitude but I remember that Windows takes surprisingly long to spin up new processes compared to Linux.

      3. 1

        The only thing worth mentioning here are rude applications that simply don’t care about stdout/stderr and interact directly with your tty, requiring things like a fake tty to actually capture & input stuff.

        1. 1

          Do you mean apps reading from (writing to) /dev/pts/* or something different?

          Also, what do you mean by faking a tty? It sounds interesting, what keywords should I look up to learn more about this?

          1. 1

            Pretty simple libs are pexpect for python or rexpect for rust. Using pseudo terminals to emulate the real terminals some applications expect. (See also Expect for the “origin” of these libs.) It’s just a gotcha as some applications won’t actually respond to controlling their stdin/out/err and you’ll fall flat on your face automating them* , typically password prompts.

            *Watch their prompt on your screen while running your own application, first time it’s like a ghost in the shell knocking on your door ;)