Reputation: 395
I'm writing a semi-realtime bash script and it's not running quite fast enough. From what I understand, Bash references some sort of table to find the full path of the commands you feed it. Would specifying the full path significantly speed up commands that are run in a loop?
Upvotes: 0
Views: 6577
Reputation: 5949
In addition to what has been said about optimizing bash
scripts, another option is not to use bash
but a more lightweight shell instead (say, sh
): bash
is large and has a comparably long startup time. If your script's execution time is short, it could actually be dominated by the bash
startup.
Upvotes: 0
Reputation: 882806
Unlikely. The bash
shell actually caches executables that it finds so only the first search will be slow.
From the bash
manpage:
If the name is neither a shell function nor a builtin, and contains no slashes, bash searches each element of the PATH for a directory containing an executable file by that name. Bash uses a hash table to remember the full path names of executable files (see hash under SHELL BUILTIN COMMANDS below). A full search of the directories in PATH is performed only if the command is not found in the hash table.
Speeding up bash
scripts usually takes the form of two things:
cut
or sed
) where the workload is small; andAs an example of the first, extracting the first character of a string with:
firstchar=$(echo $string | cut -c1-1)
is a horrible idea since it must spawn processes to do the work. You can do the exact same thing in bash
quickly with something like:
firstchar=${string:0:1}
without the relatively massive cost of spawning subprocesses.
The second point is just ensuring you choose the best tool for the job, when running subprocesses. For example, don't use a massive pipeline of multiple grep
, cut
and sed
commands when it can be done with a very simple awk
one-liner.
Upvotes: 8