4 ms·

Launching entire processes to do small operations is an antipattern. Whether a program is 1k or 10k can’t make that much difference if the minimum process spawn

Launching entire processes to do small operations is an antipattern. Whether a program is 1k or 10k can’t make that much difference if the minimum process spawn time is counted in hundreds of milliseconds? Yes, I know, it’s about the philosophy of unnecessary waste and not actually about the first kb, a philosophy I can certainly support. But still, launching a 1MB program and then launching threads from it takes a fraction of the time per thread. The 1MB process start time is quickly amortized. I know as he mentions there are situations where small processes are launched hundreds of times, but these days I think of it as a disappearing antipattern. Consider how in the past it was common with compilers to use one process to compile one source file and exit. Or how a web server would serve one request and then exit. There is a reason that went out of fashion. So the only time I’d reach for actually making a tiny executable out of performance concerns would be if I couldnt use a fatter binary and I knew the tool (for whatever reason) had to be invoked a lot, and it wasn’t under my control.

vvanders 5y ago
While I get where you're going with this however if you use small binaries that are built for efficiency then your process start time isn't 100s of ms, it's a least an order of magnitude faster. Using a single process also guarantees a higher degree of isolation and resistance to memory leaks which can be important on certain systems.
wnoise 5y ago
Processes are the natural unit for user composability and control. It's more or less necessary for any multiple language scenario. That really is worth a lot. And it makes lowering the costs for that case quite worthwhile.
chrismorgan 5y ago
> if the minimum process spawn time is counted in hundreds of milliseconds It’s not. Here’s an extremely rudimentary bash/zsh measurement, spawning a thousand processes: time (i=0; while [ $i -lt 1000 ]; do i=$(($i + 1)); /usr/bin/true; done) This is taking my Linux-running laptop 450–530ms under zsh and 300–320ms under bash, suggesting a process spawn time of under half a millisecond, not hundreds. Another variant: time (i=0; while /usr/bin/test $i -lt 1000; do i=$(($i + 1)); done) Around 540ms in zsh and 440ms in bash. I know that Windows has historically had very slow process spawn by comparison (no idea of the current situation, I just remember it being a real drag on some process-heavy makefiles I was using at work in WSL1 days), but my recollection says that even it wasn’t into hundreds of milliseconds.
- chlorion 5y ago
  1000 processes in half a second is very slow when you take into consideration how much work a modern CPU can do in a second. You could have ran though hundreds of millions of loop iterations doing some non-trivial task in the same amount of time, even on very slow machines. I'm not disagreeing about process spawn times not being extremely slow, I would have guessed a few milliseconds depending on the program, but a millisecond is a long time for a computer.
- kaba0 5y ago
  The bare idea of running a separate process as the condition of a loop is just disgusting though. I really don’t get why are we stuck with bash.
  - chrismorgan 5y ago
    It’s not disgusting, it’s a superb feature of shell scripting and a manifestation of feature composition. That you can write things like `while git diff --exit-code` is delightful.
    - kaba0 5y ago
      Yes it is good for that occasion. It is terrible for things like `test`, `true` and the like as a separate processes.
klabb3 5y ago
Slightly OT: It seems to me the industry trend of runtime-like bundling happened largely because dynamic linking and platform APIs didn't provide developers with adequate tools to build apps, for various sub-reasons. Here, I include Go, Python and electron so I'm using a broad definition that covers everything from syscalls to http stack to GUIs, on desktop, mobile and servers alike. In either case, we are now in a world where there is less and less overlap between native development stacks of different vendors. It sucks, but the tactic of shaming developers into learning and building for 5 native stacks isn't gonna fix the problem. If many apps share the same runtime, can't we deduplicate binaries and blobs on a file system level? Use copy-on-write more cleverly in ram? Anyway, I wish the solution space was geared more in the direction actual developers are already going, changes that can be scaled world wide without evangelizing some new paradigm.

vvanders 5y ago

While I get where you're going with this however if you use small binaries that are built for efficiency then your process start time isn't 100s of ms, it's a least an order of magnitude faster. Using a single process also guarantees a higher degree of isolation and resistance to memory leaks which can be important on certain systems.

wnoise 5y ago

Processes are the natural unit for user composability and control. It's more or less necessary for any multiple language scenario. That really is worth a lot. And it makes lowering the costs for that case quite worthwhile.

chrismorgan 5y ago

> if the minimum process spawn time is counted in hundreds of milliseconds It’s not. Here’s an extremely rudimentary bash/zsh measurement, spawning a thousand processes: time (i=0; while [ $i -lt 1000 ]; do i=$(($i + 1)); /usr/bin/true; done) This is taking my Linux-running laptop 450–530ms under zsh and 300–320ms under bash, suggesting a process spawn time of under half a millisecond, not hundreds. Another variant: time (i=0; while /usr/bin/test $i -lt 1000; do i=$(($i + 1)); done) Around 540ms in zsh and 440ms in bash. I know that Windows has historically had very slow process spawn by comparison (no idea of the current situation, I just remember it being a real drag on some process-heavy makefiles I was using at work in WSL1 days), but my recollection says that even it wasn’t into hundreds of milliseconds.

chlorion 5y ago
1000 processes in half a second is very slow when you take into consideration how much work a modern CPU can do in a second. You could have ran though hundreds of millions of loop iterations doing some non-trivial task in the same amount of time, even on very slow machines. I'm not disagreeing about process spawn times not being extremely slow, I would have guessed a few milliseconds depending on the program, but a millisecond is a long time for a computer.
kaba0 5y ago
The bare idea of running a separate process as the condition of a loop is just disgusting though. I really don’t get why are we stuck with bash.
- chrismorgan 5y ago
  It’s not disgusting, it’s a superb feature of shell scripting and a manifestation of feature composition. That you can write things like `while git diff --exit-code` is delightful.
  - kaba0 5y ago
    Yes it is good for that occasion. It is terrible for things like `test`, `true` and the like as a separate processes.

klabb3 5y ago

Slightly OT: It seems to me the industry trend of runtime-like bundling happened largely because dynamic linking and platform APIs didn't provide developers with adequate tools to build apps, for various sub-reasons. Here, I include Go, Python and electron so I'm using a broad definition that covers everything from syscalls to http stack to GUIs, on desktop, mobile and servers alike. In either case, we are now in a world where there is less and less overlap between native development stacks of different vendors. It sucks, but the tactic of shaming developers into learning and building for 5 native stacks isn't gonna fix the problem. If many apps share the same runtime, can't we deduplicate binaries and blobs on a file system level? Use copy-on-write more cleverly in ram? Anyway, I wish the solution space was geared more in the direction actual developers are already going, changes that can be scaled world wide without evangelizing some new paradigm.