2 ms·

Much faster in theory, unnoticeable in practice. I assume nobody does number crunching using shell scripts.

arp242 3y ago
You don't need to do "number crunching"; the performance differences are very real even for simple scripts on modern systems. Launching a process is comparatively expensive (read binary from disk, run linker, allocate new process space in kernel, etc.) whereas a builtin is just "if progname == "[" { .. }". And when you do something like "loop over a few thousand files" the difference really adds up. Consider this example: for i in $(seq 1 10); do for f in /*; do if [ $f = /etc ]; then : # Do nothing. fi done done I have 23 entries in /, so this will run [ 230 times – not a crazy number. % time sh test sh test 0.00s user 0.01s system 91% cpu 0.009 total bash, dash, zsh: they all have roughly the same performance: "fast enough to be practically instantaneous". But if I replace [ with /bin/[: % time sh test sh test 0.11s user 0.38s system 96% cpu 0.509 total Half a second! That's tons slower! And you can keep "fast enough to be practically instantaneous" for thousands of files with the built-in [, whereas it will take many seconds with /bin/[. (Aside: if I statically link [ it's about 0.4 seconds).
- usr1106 3y ago
  I know what it costs to start a process. My point is just if that script is done in 0.5 seconds that's good enough for me as an occasional human caller. I don't care that it could be much faster. Of course if the script were to handle all files of a filesystem with many small files it could get disturbingly slow. I don't deny that there are cases were it matters. But in over 90% of the scripts I write or use it doesn't.
  - arp242 3y ago
    230 files is hardly "all files of a filesystem", and if you run [ 2 or 3 times per file it becomes even slower. Many scripts are little more than glorified for-loops, and "run this on a bunch of files" in particular is a major use case of shell scripts, which is also why we have find -print0, find -exec{} \+, etc. It's up to you whether half a second is "fast enough" (just an example: can easily also be 2 seconds, or 5 seconds), but it's definitely a lot slower than 9ms and not "only much faster in theory", or "unnoticeable in practice", and "number crunching" doesn't come in to play regardless. Since the cost of this optimisation is minimal (you can just use the source of /bin/[ as a builtin) I don't see why anyone would choose half a second over 9ms.

You don't need to do "number crunching"; the performance differences are very real even for simple scripts on modern systems. Launching a process is comparatively expensive (read binary from disk, run linker, allocate new process space in kernel, etc.) whereas a builtin is just "if progname == "[" { .. }". And when you do something like "loop over a few thousand files" the difference really adds up. Consider this example: for i in $(seq 1 10); do for f in /*; do if [ $f = /etc ]; then : # Do nothing. fi done done I have 23 entries in /, so this will run [ 230 times – not a crazy number. % time sh test sh test 0.00s user 0.01s system 91% cpu 0.009 total bash, dash, zsh: they all have roughly the same performance: "fast enough to be practically instantaneous". But if I replace [ with /bin/[: % time sh test sh test 0.11s user 0.38s system 96% cpu 0.509 total Half a second! That's tons slower! And you can keep "fast enough to be practically instantaneous" for thousands of files with the built-in [, whereas it will take many seconds with /bin/[. (Aside: if I statically link [ it's about 0.4 seconds).

usr1106 3y ago
I know what it costs to start a process. My point is just if that script is done in 0.5 seconds that's good enough for me as an occasional human caller. I don't care that it could be much faster. Of course if the script were to handle all files of a filesystem with many small files it could get disturbingly slow. I don't deny that there are cases were it matters. But in over 90% of the scripts I write or use it doesn't.
- arp242 3y ago
  230 files is hardly "all files of a filesystem", and if you run [ 2 or 3 times per file it becomes even slower. Many scripts are little more than glorified for-loops, and "run this on a bunch of files" in particular is a major use case of shell scripts, which is also why we have find -print0, find -exec{} \+, etc. It's up to you whether half a second is "fast enough" (just an example: can easily also be 2 seconds, or 5 seconds), but it's definitely a lot slower than 9ms and not "only much faster in theory", or "unnoticeable in practice", and "number crunching" doesn't come in to play regardless. Since the cost of this optimisation is minimal (you can just use the source of /bin/[ as a builtin) I don't see why anyone would choose half a second over 9ms.