The parallelism provides potentially huge speed increases over a normal bash loop (not to mention ease of use, no script file or complex oneliner required). If you clone the repo you can try `./benchmark`, and/or `./benchmark <am repetitions> <any command of your choice>` to run a benchmark on the cmd, check out the script `benchmark` script for more details.
I don't know much about GNU parallel, I'll investigate it and see if I can add it to the benchmark script so it's possible to compare.
I'm not that interested in benchmarking what will likely show negligible performance differences for the things I might use this for.
I try to avoid installing anything out of the mainstream on production servers, and keep dev servers as close to production as possible. That means any new tool or application has to more than pay its way with new or much improved functionality over out-of-the-box tools like bash/zsh, built-in job control (backgrounding), xargs, and GNU parallel. Not everyone has the same concerns but I've found my development and deployment experience stays simple and predictable if I keep third-party dependencies to the bare minimum.
7 comments
[ 4.4 ms ] story [ 26.3 ms ] threadThe parallelism provides potentially huge speed increases over a normal bash loop (not to mention ease of use, no script file or complex oneliner required). If you clone the repo you can try `./benchmark`, and/or `./benchmark <am repetitions> <any command of your choice>` to run a benchmark on the cmd, check out the script `benchmark` script for more details.
I don't know much about GNU parallel, I'll investigate it and see if I can add it to the benchmark script so it's possible to compare.
I try to avoid installing anything out of the mainstream on production servers, and keep dev servers as close to production as possible. That means any new tool or application has to more than pay its way with new or much improved functionality over out-of-the-box tools like bash/zsh, built-in job control (backgrounding), xargs, and GNU parallel. Not everyone has the same concerns but I've found my development and deployment experience stays simple and predictable if I keep third-party dependencies to the bare minimum.
https://www.gnu.org/software/parallel/parallel_alternatives....
$ ruby -e '10.times { puts 1; sleep 1 }'