4 ms·
> 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
by 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 ago1000 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 agoThe 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 agoIt’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 agoYes it is good for that occasion. It is terrible for things like `test`, `true` and the like as a separate processes.