I disagree that when programming in bash, performance should not bother. This is actually a very good question.
Here you can find a comparative test comparing the built-in true and the true command, the full path of which on my machine is /bin/true .
On my car:
$ time for i in {0..1000}; do true; done real 0m0.004s user 0m0.004s sys 0m0.000s $ time for i in {0..1000}; do /bin/true; done real 0m2.660s user 0m2.880s sys 0m2.344s
Awesome! This is about 2 to 3 ms in vain, just by drawing a process (on my machine)!
So, the next time you have a large text file processed, you will avoid long chains with a chain cat s, grep s, awk s, cut s, tr s, sed s, head s, tail s, you-name-it s. Also, unix channels are also very slow (will this be your next question?).
Imagine you have a file with 1000 lines, and if you put one cat on each line, then a grep , then a sed , and then awk (no, don’t laugh, you can see even worse by looking at the messages on this site! ), then you are already losing (on my machine) at least 2 * 4 * 1000 = 8000ms = 8s, just playing out silly and useless processes.
Update . To answer your comments about pipes ...
Subshells
Sneakers are very slow:
$ time for i in {1..1000}; do (true); done real 0m2.465s user 0m2.812s sys 0m2.140s
Awesome! more than 2 ms per subshell (on my machine).
Pipes
Pipes are also very slow (this should be obvious in that they include subshells):
$ time for i in {1..1000}; do true | true; done real 0m4.769s user 0m5.652s sys 0m4.240s
Awesome! more than 4 ms per pipe (on my machine), so 2 ms only for the pipe (subtracting the time for the subshell).
Redirection
$ time for i in {1..1000}; do true > file; done real 0m0.014s user 0m0.008s sys 0m0.008s
So pretty fast.
Well, you probably also want to see it in action with the creation of the file:
$ rm file*; time for i in {1..1000}; do true > file$i; done real 0m0.030s user 0m0.008s sys 0m0.016s
Still decently fast.
Pipes against redirection:
In your comment you mentioned:
sed '' filein > filetmp; sed '' filetmp > fileout
vs
sed '' filein | sed '' > fileout
(Of course, it is best to use a single sed instance (this is usually possible), but this does not answer the question.)
Check this:
The funny way:
$ rm file* $ > file $ time for i in {1..1000}; do sed '' file | sed '' > file$i; done real 0m5.842s user 0m4.752s sys 0m5.388s $ rm file* $ > file $ time for i in {1..1000}; do sed '' file > filetmp$i; sed '' filetmp$i > file$i; done real 0m6.723s user 0m4.812s sys 0m5.800s
So it’s faster to use the handset than to use a temporary file (for sed). In fact, this could be understood without entering lines: in the pipe, as soon as the first sed spits out something, the second sed starts processing the data. In the second case, the first sed does its work, and then the second sed does its work.
Thus, our experiment is not a good way to determine if redirection channels are better.
How about replacing the process?
$ rm file* $ > file $ time for i in {1..1000}; do sed '' > file$i < <(sed '' file); done real 0m7.899s user 0m1.572s sys 0m3.712s
Wow, this is slow! Hey, but pay attention to the use of user and system processors: much less than the other two possibilities (if someone can explain this ...)